JUnit - should I assign null to resources in tearDown that were instantiated in setUp?

Question

I am reading one book about JUnit now and writer advises nulling resources in tearDown method. Why? Isn't this GC's job? Can it seriously make any harm?

Lets think of example like this:

public class SomeTest extends TestCase {
  Vector vector;
  List<Object> list;  

  protected void setUp() {
    vector = new Vector();
    list = new ArrayList<Object>();
  }

  // messing with resources
  // adding, deleting, testing whatever

  protected void tearDown() {
    vector = null;
    list = null;
  }
}

What do you think? Is that code in tearDown necessary?

Michael Borgwardt · Accepted Answer · 2010-09-08T09:13:51.380

10

Yes, this can indeed be necessary.

You see, JUnit will actually create a separate instance of the Test class for each test method, and the Junit3 test runner (not so with JUnit4) will keep these instances around until the entire test suite has finished.

Therefore, if your (JUnit3) test class has fields that take up a lot of memory, you can easily run out of heap space when you have a large number of test methods. Of course, if those collections in your example code only ever contain a handful of short strings, it doesn't matter.

edited Sep 08 '10 at 09:13

answered Sep 06 '10 at 18:56

Michael Borgwardt

342,105
78
482
720

Ok ... thanx everyone for help but this is most interesting answer for me, so I mark it as accepted. – Xorty Sep 06 '10 at 19:05
3

JUnit4 does indeed create a different object for each test method, but it will not keep these instances around until the entire test suite has finished. See my response to http://stackoverflow.com/questions/3655944/is-it-really-necessary-to-nullify-objects-in-junit-teardown-methods – NamshubWriter Sep 07 '10 at 16:43

score 3 · Answer 2 · answered Sep 06 '10 at 18:37

3

It depends what you consider a resource. Whilst heap space is a resource, you can probably get away with the GC cleaning up after you (YMMV).

Things that might cause issues are Closables like database connections / open files and streams etc. which should always be closed after use to prevent nasties in long running code.

I once had a situation that an integration test for some hibernate code didn't cleanup properly and resulted in some really strange errors. It took many hours to find and angered me so badly that I'll never make the same mistake again.

answered Sep 06 '10 at 18:37

gpampara

11,989
3
27
26

I see this is the thing. Author should have written so :) So for example I posted above, it's useless, right ? – Xorty Sep 06 '10 at 18:41
Yes :) Your test case should be fine. I generally try to avoid @Before and @After cases - just do them where needed. – gpampara Sep 07 '10 at 05:30
If SomeTest was part of a very large TestSuite with many TestCases, and somes TestCases in that TestSuite create objects in setUp() that take up a lot of memory and do not null out the references in tearDown(), then yes, you could run low on memory while running the suite. Note that the answer is different for JUnit 4.x style tests. – NamshubWriter Sep 07 '10 at 15:01

score 2 · Answer 3 · answered Apr 04 '15 at 01:37

JUnit 4.x style tests and test suites handle this differently than JUnit 3.x test suites.

TL;DR: you should set fields to null in JUnit3-style tests but you do not need to in JUnit4-style tests.

With JUnit 3.x style tests, a TestSuite contains references to other Test objects (which may be TestCase objects or other TestSuite objects). If you create a suite with many tests, then there will be hard references to all of the leaf TestCase objects for the entire run of the outermost suite. If some of your TestCase objects allocate objects in setUp() that take up a lot of memory, and references to those objects are stored in fields that are not set to null in tearDown(), then you might have a memory problem.

In other words, for JUnit 3.x style tests, the specification of which tests to run references the actual TestCase objects. Any objects reachable from a TestCase object will be kept in memory during the test run.

For JUnit 4.x style tests, the specification of which tests to run uses Description objects. The Description object is a value object that specifies what to run, but not how to run it. The tests are run by a Runner object that takes the Description of the test or suite and determines how to execute the test. Even the notification of the status of the test to the test listener uses the Description objects.

The default runner for JUnit4 test cases, JUnit4, keeps a reference to the test object around only for the duration of the run of that test. If you use a custom runner (via the @RunWith annotation), that runner may or may not keep references to the tests around for longer periods of time.

Perhaps you are wondering what happens if you include a JUnit3-style test class in a JUnit4-style Suite? JUnit4 will call new TestSuite(Class) which will create a separate TestCase instance per test method. The runner will keep a reference to the TestSuite for the entire life of the test run.

In short, if you are writing JUnit4-style tests, do not worry about setting your test case's fields to null in a tear down (do, of course, free resources). If you are writing JUnit3-style tests that allocate large objects in setUp() and store those objects in fields of the TestCase, consider setting the fields to null.

JUnit - should I assign null to resources in tearDown that were instantiated in setUp?

3 Answers3

Linked

Related