setUp/tearDown (@Before/@After) why we need them in JUnit?

by

This (old) JUnit best practices article puts it like this:

Do not use the test-case constructor to set up a test case

Setting up a test case in the
constructor is not a good idea.
Consider:

public class SomeTest extends TestCase
   public SomeTest (String testName) {
      super (testName);
      // Perform test set-up
   }
}

Imagine that while performing the
setup, the setup code throws an
IllegalStateException. In response,
JUnit would throw an
AssertionFailedError, indicating that
the test case could not be
instantiated. Here is an example of
the resulting stack trace:

junit.framework.AssertionFailedError: Cannot instantiate test case: test1   
    at junit.framework.Assert.fail(Assert.java:143)
    at junit.framework.TestSuite.runTest(TestSuite.java:178)
    at junit.framework.TestCase.runBare(TestCase.java:129)
    at junit.framework.TestResult.protect(TestResult.java:100)
    at junit.framework.TestResult.runProtected(TestResult.java:117)
    at junit.framework.TestResult.run(TestResult.java:103)
    at junit.framework.TestCase.run(TestCase.java:120)
    at junit.framework.TestSuite.run(TestSuite.java, Compiled Code)
    at junit.ui.TestRunner2.run(TestRunner.java:429)

This stack trace proves rather
uninformative; it only indicates that
the test case could not be
instantiated. It doesn’t detail the
original error’s location or place of
origin. This lack of information makes
it hard to deduce the exception’s
underlying cause.

Instead of setting up the data in the
constructor, perform test setup by
overriding setUp(). Any exception
thrown within setUp() is reported
correctly. Compare this stack trace
with the previous example:

java.lang.IllegalStateException: Oops
    at bp.DTC.setUp(DTC.java:34) 
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult.protect(TestResult.java:100)
    at junit.framework.TestResult.runProtected(TestResult.java:117)
    at junit.framework.TestResult.run(TestResult.java:103)
    ...

This stack trace is much more
informative; it shows which exception
was thrown (IllegalStateException) and
from where. That makes it far easier
to explain the test setup’s failure.

More Related Contents:

  1. Does Junit reinitialize the class with each test method invocation?
  2. How do you assert that a certain exception is thrown in JUnit 4 tests?
  3. Difference between @Before, @BeforeClass, @BeforeEach and @BeforeAll
  4. How to run test methods in specific order in JUnit4?
  5. How do you assert that a certain exception is thrown in JUnit tests?
  6. Getting “NoSuchMethodError: org.hamcrest.Matcher.describeMismatch” when running test in IntelliJ 10.5
  7. Changing names of parameterized tests
  8. How to test that no exception is thrown?
  9. No tests found with test runner ‘JUnit 4’
  10. How do I Dynamically create a Test Suite in JUnit 4?
  11. How to run all tests belonging to a certain Category in JUnit 4
  12. How does Junit @Rule work?
  13. Is Java’s assertEquals method reliable?
  14. java.lang.Exception: No runnable methods exception in running JUnits
  15. Has JUnit4 begun supporting ordering of test? Is it intentional?
  16. How to define a JUnit method rule in a test suite?
  17. differences between 2 JUnit Assert classes
  18. How to run all JUnit tests in a category/suite with Ant?
  19. Why is assertEquals(double,double) deprecated in JUnit?
  20. JUnit 4 @BeforeClass & @AfterClass when using Suites
  21. java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
  22. JUnit confusion: use ‘extends TestCase’ or ‘@Test’?
  23. Eclipse – debugger doesn’t stop at breakpoint
  24. How to mock new Date() in java using Mockito
  25. SpringRunner vs SpringBootTest
  26. Where do I configure log4j in a JUnit test class?
  27. CollectionAssert in jUnit?
  28. Junit Test of Setters and Getters of Instance Variables
  29. NoSuchFieldError when trying to run a jUnit test with Spring
  30. Why are my mocked methods not called when executing a unit test?

Leave a Comment