• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Garbage Collection and Junit

 
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was wondering while testing with Junit; considering that the test runner holds strong references to all test instances, is setting different objects to null in the tearDown() method best practice to save resources, or should garbage collection be left to java?

Thanks
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally I would instantiate the references needed before each test within a method annotated with @Before. Whenever you're able to use the same reference for all tests I would instantiate these within a method annotated with @BeforeClass. The @Before annotated method will be executed before each test, making the old references eligible for GC automatically. The @BeforeClass annotated method will only be executed once before running the tests. So yes, leave the GC to Java. Although you can, there is no need to explicitly point object references to null. Java is perfectly capable to determine when objects are eligible for GC.
 
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would recommend destroying test objects as soon as possible. When you've got lots of tests and are possibly running under a complex testing VM (such as Maven), it's not only desirable from the viewpoint of tossing as much stuff into garbage as soon as possible, it also reduces lint and thereby makes it possible to more reliably repeat the same test more than once in a given VM.

Of course, once a VM terminates, the VM shutdown nukes everything, but as a general rule, I do recommend discarding stuff once it's no longer useful, whether in testing or live code.
 
Saloon Keeper
Posts: 12154
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In JUnit 3, you should null out fields in your tear down methods, because JUnit keeps an instance of the test class in memory for every test method run.

JUnit 4 discards the test objects as soon as the test is finished, so you don't need to null out its fields. Use the tear down method to dispose resources.
 
Jake Monhan
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone for your input. It loos like although I'm using JUnit4, some resource management in tear down method is good housekeeping practice.
 
Tim Holloway
Saloon Keeper
Posts: 22273
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jake Monhan wrote:Thanks everyone for your input. It loos like although I'm using JUnit4, some resource management in tear down method is good housekeeping practice.



It's OK to let junit destroy what junit created. But definitely if you create something yourself and you link it to something that doesn't get automatically destroyed then you should unlink it when the test is done. Junit can't destroy things it doesn't know about.
 
Jake Monhan
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junit can't destroy things it doesn't know about.



Of course I definitely agree with your point about taking care of such things as closing IO's and delinking resources which had been setup in the @Before and @BeforeClass sections, just being a responsible design. But then again as you mentioned in your earlier post, those steps should be taken in any application, not just in test applications.
    Bookmark Topic Watch Topic
  • New Topic