JUnit

Every JUnit test class usually has several test cases. These test cases are subject to the test life cycle. The full JUnit Life Cycle has three major phases:[5]

1. Setup phase - This phase is where the test infrastructure is prepared. Two levels of setup are available. The first type of setup is class-level setup in which a computationally expensive object, such as a database connection, is created and reused, with minimal side effects. Class-level setup is implemented using the @BeforeAll annotation. The other type is setup before running each test case, which uses the @BeforeEach annotation.[5]
2. Test execution - This phase is responsible for running the test and verifying the result. The test result will indicate if the test result is a success or a failure. The @Test annotation is used here.[5]
3. Clean up phase - After all posttest executions are performed, the system may need to perform cleanup. Similar to class-level setup, there is a corresponding class-level clean up. The @AfterAll annotation is used to support class-level clean up. The @AfterEach annotation allows for cleanup after test execution.[5]

JUnit 5 integrates a number of tools, such as build tools, integrated development environments (IDE), continuous integration (CI) tools and many more.[6]

JUnit follows the paradigm of preferring extension points over features.[14] The JUnit team decided not to put all features within the JUnit core, and instead decided to give an extensible way for developers to address their concerns.[14]

In JUnit 4, there are two extension mechanisms: the Runner API and Rule API.[15] There were some disadvantages to both the Runner API and the Rule API.

A major limitation of the Runner API is that the developer has to implement the entire life cycle even if they only need a specific life cycle stage.[15] This is too complicated and heighweight for the majority of use cases.[15] Another major limitation is that only one runner class is used for each test case, and makes them uncomposable.[15] As an example, Mockito and Parameterized runners cannot exist within the same test class.[15]

A major limitation of the Rule API is that it cannot control the entire life cycle of the test, so they cannot be used for every single use case.[15] They are only appropriate when something needs to occur before or after test case execution.[15] Another major limitation is that rules for class-level and method-level callbacks must be made separately.[15]

In JUnit 5, the extension API is found within the JUnit Jupiter Engine.[16] The JUnit Team wants to allow the developer to hook to separate stages of a test life cycle by providing a single unified extension API.[16] Upon reaching a certain life cycle phase, the Jupiter Engine will invoke all registered extensions for that phase.[16] The developer can hook into five major extension points:[16]

1. Test life cycle callbacks - This allows the developer to hook to certain phases of a test life cycle[17]
2. Test instance post-processing - this enables the developer to hook after test instance creation by implementing the TestInstancePostProcessor interface.[18]
3. Conditional test execution - this enables the developer to execute the test case only after meeting certain criteria.[19]
4. Parameter resolution - This enables the developer to resolve a parameter after receiving it from a test method or constructor.
5. Exception handling - A use case for exception handling is to change the testing behavior instead of throwing an exception.[20]

A JUnit test fixture is a Java object. Test methods must be annotated by the @Test annotation. If the situation requires it,[21] it is also possible to define a method to execute before (or after) each (or all) of the test methods with the @BeforeEach (or @AfterEach) and @BeforeAll (or @AfterAll) annotations.[22][23]

import org.junit.jupiter.api.*;

class FoobarTests {
    @BeforeAll
    static void setUpClass() throws Exception {
        // Code executed before the first test method
    }

    @BeforeEach
    void setUp() throws Exception {
        // Code executed before each test
    }
 
    @Test
    void oneThing() {
        // Code that tests one thing
    }

    @Test
    void anotherThing() {
        // Code that tests another thing
    }

    @Test
    void somethingElse() {
        // Code that tests something else
    }

    @AfterEach
    void tearDown() throws Exception {
        // Code executed after each test 
    }
 
    @AfterAll
    static void tearDownClass() throws Exception {
        // Code executed after the last test method 
    }
}

According to Martin Fowler, one of the early adopters of JUnit:[24]

JUnit was born on a flight from Zurich to the 1997 OOPSLA in Atlanta. Kent was flying with Erich Gamma, and what else were two geeks to do on a long flight but program? The first version of JUnit was built there, pair programmed, and done test first (a pleasing form of meta-circular geekery).

As a side effect of its wide use, previous versions of JUnit remain popular, with JUnit 4 having over 100,000 usages by other software components on the Maven Central repository.[25]

In JUnit 4, the annotations for test execution callbacks were @BeforeClass, @Before, @After, and @AfterClass, as opposed to JUnit 5's @BeforeAll, @BeforeEach, @AfterEach, and @AfterAll.[22][23]

In JUnit 3, test fixtures had to inherit from junit.framework.TestCase.[26] Additionally, test methods had to be prefixed with 'test'.[27]

• xUnit, the family name given to testing frameworks including JUnit
• SUnit, the original Smalltalk version written by Kent Beck based on which JUnit was written
• TestNG, another test framework for Java
• Mock object, a technique used during unit testing
• Mockito, a mocking library to assist in writing tests
• EvoSuite, a tool to automatically generate JUnit tests
• List of Java Frameworks

• Gulati, Shekhar; Sharma, Rahul (2017). Java Unit Testing with JUnit 5. Berkeley, CA: Apress. doi:10.1007/978-1-4842-3015-2. ISBN 978-1-4842-3014-5.

• Official website
• Irriger, Axel. "JUnit - Open Source Java Unit Testing Tool". Methods and Tools.
• "JUnit". Memory Not Found. Tutorials. Archived from the original on Jan 28, 2015.