Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JUnit confusion: use 'extends TestCase' or '@Test'?

People also ask

Which of the following is a JUnit extension?

There are several JUnit extensions such as: JWebUnit. XMLUnit. Cactus.

What is the use of JUnit test cases?

JUnit is the most famous framework for writing unit tests in Java. You write test methods that call the actual methods to be tested. The test case verifies the behavior of the code by asserting the return value against the expected value, given the parameters passed.

Which of the following is correct about a unit test case?

Q 10 - Which of the following is correct about a Unit Test Case? A - A Unit Test Case is a part of code which ensures that the another part of code (method) works as expected.


The distinction is rather easy:

  • extending TestCase is the way unit tests were written in JUnit 3 (of course it's still supported in JUnit 4)
  • using the @Test annotation is the way introduced by JUnit 4

Generally you should choose the annotation path, unless compatibility with JUnit 3 (and/or a Java version earlier than Java 5) is needed. The new way has several advantages:

  • The @Test annotation is more explicit and is easier to support in tools (for example it's easy to search for all tests this way)
  • Multiple methods can be annotated with @Before/@BeforeClass and @After/@AfterClass providing more flexibility
  • Support for @Rule annotations on things like ExpectedException
  • Support for the @Ignored annotation
  • Support for alternative test runners using @RunWith

To test for expected exceptions in a JUnit 3 TestCase you'd have to make the text explicit.

public void testMyException() {
  try {
    objectUnderTest.myMethod(EVIL_ARGUMENT);
    fail("myMethod did not throw an Exception!");
  } catch (MyException e) {
    // ok!
    // check for properties of exception here, if desired
  }
}

JUnit 5 introduced yet another API change, but still uses annotations. The new @Test annotation is org.junit.jupiter.api.Test (the "old" JUnit 4 one was org.junit.Test), but it works pretty much the same as the JUnit 4 one.


I have a preference for JUnit 4 (Annotation approach) because I find it more flexible.

If you want to build test suite in JUnit 4, you have to create a class grouping all tests like this:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;


@RunWith(Suite.class)
@SuiteClasses({
    Test1.class,
    Test2.class,
    Test3.class,
    Test4.class
})public class TestSuite
{
 /* empty class */
}

There is an unanswered part to your question, and that is "What is the proper way to group tests for approach B?"

The official answer is that you annotate a class with an @RunWith(Suite.class) and then use the @Suite.SuiteClasses annotation to list the classes. This is how the JUnit developers do it (listing every class in a suite manually). In many ways this approach is an improvement, in that it is trivial and intuitive to add before suite and after suite behaviors (just add an @BeforeClass and @AfterClass method to the the class annotated with the @RunWith - much better than the old TestFixture).

However, it does have a step backwards, in that annotations don't allow you to dynamically create the list of classes, and working around that problem gets a bit ugly. You have to subclass the Suite class and dynamically create the array of classes in the subclass and pass it to the Suite constructor, but this is an incomplete solution in that other subclasses of Suite (such as Categories) don't work with it and essentially do not support dynamic Test class collection.


You should use JUnit 4. It's better.

Much frameworks have started to deprecate the JUnit 3.8 support.

This is from the Spring 3.0 reference documentation:

[Warning] Legacy JUnit 3.8 class hierarchy is deprecated

In general, you should always try to use the latest stable release of a framework when you start something new.


  1. The "preferred" approach would be to use annotations which have been introduced since Junit 4. They make a lot of things easier (see your second question)

  2. You can use a simple try/catch block for that:


public void testForException() {
    try {
        Integer.parseInt("just a string");
        fail("Exception should have been thrown");
    } catch (final Exception e) {
        // expected
    }
}