Developer(s) | Kent Beck, Erich Gamma, David Saff, Kris Vasudevan |
---|---|
Stable release | 5.10.0
/ July 23, 2023[1] |
Written in | Java |
Operating system | Cross-platform |
Type | Unit testing tool |
License | Eclipse Public License 2.0[2] (relicensed previously) |
Website | junit |
JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit.
JUnit is linked as a JAR at compile-time. The latest version of the framework, JUnit 5, resides under package org.junit.jupiter
.[3] Previous versions JUnit 4[3] and JUnit 3 were under packages org.junit
and junit.framework
, respectively.
A research survey performed in 2013 across 10,000 Java projects hosted on GitHub found that JUnit (in a tie with slf4j-api) was the most commonly included external library. Each library was used by 30.7% of projects.[4]
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]
@BeforeAll
annotation. The other type is setup before running each test case, which uses the @BeforeEach
annotation.[5]@Test
annotation is used here.[5]@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 supports Apache Ant, Apache Maven and Gradle build tools, which are the most widely used project build tools. [7] Build tools are vital for automating the process of building the project. [6]
Apache Ant, also known as Ant, is one of the build tools with the highest degree of versatility, and has the longest history out of the three build tools listed above.[8] Ant centers around the build.xml
file, used for configuring the tasks necessary to run a project.[8] Ant also has an extension called Apache Ivy, which helps deal with dependency resolution. The project dependencies can be declared in the ivy.xml
file. Ant can integrate with JUnit 5 by configuring the Java code coverage tools (JaCoCo), for the ivy.xml
file.[8] The ivy.xml
can then be configured with the java-platform-console
and junit-platform-runner
dependencies to integrate with JUnit 5. [9]
In contrast to Ant, Apache Maven, also known as Maven, uses a standardized and unified approach to the build process.[10] Maven follows the paradigm of "convention over configuration" for managing its dependencies.[11] The Java source code (or "src") can be found under the src/main/java
directory, and the test files can be found under the src/test/java
directory.[11] Maven can be used for any Java Project.[10] It uses the Project Object Model (POM), which is an XML-based approach to configuring the build steps for the project.[10] The minimal Maven with the pom.xml
build file must contain a list of dependencies and a unique project identifier.[10] Maven must be available on the build path to work.[10] Maven can integrate with JUnit 5 using the jacoco-maven-plugin
plugin which supports out-of-box functionality for JUnit 5 tests.[12] Different Maven goals can be specified to achieve these tasks.[12]
Gradle is a build tool that borrows many concepts from its predecessors, Ant and Maven.[11] It uses the build.gradle
file to declare the steps required for the project build.[11] Unlike Ant and Maven, which are XML-based, Gradle requires the use of Apache Groovy, which is a Java-based programming language.[11] Unlike Ant and Maven, Gradle does not require the use of XML.[11] Gradle still adheres to Maven's "convention over configuration" approach, and follows the same structure for src/main/java
and src/test/java
directories.[11] Gradle can integrate with JUnit 5 by configuring a plugin jacoco
alongside the junit-platform plug-in given by the JUnit 5 team in the build file.[13]
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]
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]
Original source: https://en.wikipedia.org/wiki/JUnit.
Read more |