• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Looking for example of necessary tearDown( )

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I'm quite familiar with the purpose of tearDown(), I just fail to see the necessity of it. According to M. Feathers' "Working effectively with legacy code" unit tests don't access databases or communicate via a nreal network connection. I do know that his book's focus is not on JUnit, but I do think that he has a point there. So: without a database and a network connection, when it is really necessary to free up resources with tearDown()? Isn't garbage collecting enough?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't remember a situation were I used tearDown. Still, it's nice to know that I could if I needed to...

And frankly, you *can* use JUnit for non-unit testing - such as integration testing, functional testing etc. I guess in those cases, tearDown can become quite useful.
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some junit test runners keep a reference to each test that have been run, so for very large test suites where each test creates memory-intensive objects in setUp() (e.g. using StrutsTestCase, JWebUnit, etc...) it is indeed necessary to set your instance variables to null in tearDown() in order to avoid OutOfMemoryExceptions.

For plain junit tests it's probably not necessary, but I still find it good practice to clean up in tearDown().
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To clarify: the test runner keeping a reference to the test instance prevents any objects allocated by it to be garbage collected until it's finished.

Of course, StrutsTestCase and JWebUnit isn's really used for unit testing, rather integration or functional testing. It is however theoretically possible to imagine that the same problem could arise in an extremely large suite of unit tests. It all depends on the memory constraints.
 
Mike Himstead
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mattias Arthursson:
To clarify: the test runner keeping a reference to the test instance prevents any objects allocated by it to be garbage collected until it's finished...



Pardon me for being so noisy, but why would they keep the reference? For displaying the results? Shouldn't it be possible to show them without a reference to the test? Or for a quick re-run?
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mike Himstead:
Pardon me for being so noisy, but why would they keep the reference? For displaying the results? Shouldn't it be possible to show them without a reference to the test? Or for a quick re-run?


It's a fair question, and one I have asked myself on several occations. It should indeed be possible to show the results without an actual reference. The fact remains though.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure why they did, but I think they changed that in JUnit 4.
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It seems it's not the TestRunner that is to blame for this but rather TestSuite. It creates each test instance (i.e. one for each test method in each test class) on initialization. I guess that TestSuite being dynamic requires it to have references to each actual Test instance.

Anyway, the result is the same - there are references to each actual test instance throughout the full test run, preventing any objects referenced by them to be garbage collected.

An interesting side effect is that this becomes even worse if you create objects in the constructor of your TestCase (or in the declaration of a field) - that will potentially allocate huge amounts of memory before test execution even started, which means that it doesn't even matter if you clean up in tearDown().

Conclusion: all references should be created in setUp() and released in tearDown().

I have no idea whether this applies to JUnit4 though.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends on the definition you use for a unit test. Can it involve the file system?

If so, you would need to clean up a file created in the setup.
reply
    Bookmark Topic Watch Topic
  • New Topic