Editing JUnit

{{Short description|Java testing framework}}
{{Redirect|Junit|the Egyptian goddess|Iunit}}
{{Infobox software
| name = JUnit
| logo = 
| screenshot = 
| caption = 
| developer = [[Kent Beck]], [[Erich Gamma]], David Saff
| latest release version = 5.10.0
| latest release date = {{release date and age|2023|07|23}}<ref name="github">{{cite web|url=https://github.com/junit-team/junit5/releases|website=github.com|title=JUnit Releases |access-date=2023-07-23}}</ref>
| operating system = [[Cross-platform]]
| programming language = [[Java programming language|Java]]
| genre = [[Unit testing]] tool
| license = [[Eclipse Public License 2.0]]<ref>{{cite web | url=https://github.com/junit-team/junit5/issues/1045 | title=Change license to EPL v2.0 | website=github.com | date=7 September 2017 | access-date=2021-02-04}}</ref> ([[Software relicensing|relicensed]] previously)
| website = {{URL|https://junit.org}}
}}

'''JUnit''' is a [[test automation]] [[Software framework|framework]] for the [[Java (programming language)|Java programming language]]. JUnit is often used for [[unit testing]], and is one of the [[xUnit]] frameworks.

JUnit is linked as a [[JAR (file format)|JAR]] at compile-time. The latest version of the framework, JUnit 5, resides under package {{code|org.junit.jupiter}}.{{sfn|Gulati|Sharma|2017|loc=§Chapter 8 Dynamic Tests and Migration from Junit 4|p=144}} Previous versions JUnit 4{{sfn|Gulati|Sharma|2017|loc=§Chapter 8 Dynamic Tests and Migration from Junit 4|p=144}} and JUnit 3 were under packages {{code|org.junit}} and {{code|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|slf4j-api]]) was the most commonly included external library. Each library was used by 30.7% of projects.<ref>{{cite web |url=http://www.takipiblog.com/2013/11/20/we-analyzed-30000-github-projects-here-are-the-top-100-libraries-in-java-js-and-ruby/ |title=We Analyzed 30,000 GitHub Projects – Here Are The Top 100 Libraries in Java, JS and Ruby |access-date=2014-02-09 |archive-date=2014-07-09 |archive-url=https://web.archive.org/web/20140709221250/http://www.takipiblog.com/2013/11/20/we-analyzed-30000-github-projects-here-are-the-top-100-libraries-in-java-js-and-ruby/ |url-status=dead }}</ref>

==JUnit Lifecycle==
Every JUnit test class usually has several test cases. These test cases are subject to the test life cycle. The full JUnit Lifecycle has three major phases:{{sfn|Gulati|Sharma|2017|loc=Chapter §2 JUnit LifeCycle API|pp=37-40}}
# 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 {{code|@BeforeAll}} annotation. The other type is setup before running each test case, which uses the {{code|@BeforeEach}} annotation.{{sfn|Gulati|Sharma|2017|loc=Chapter §2 JUnit LifeCycle API|pp=37-40}}
# 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 {{code|@Test}} annotation is used here.{{sfn|Gulati|Sharma|2017|loc=Chapter §2 JUnit LifeCycle API|pp=37-40}}
# 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 {{code|@AfterAll}} annotation is used to support class-level clean up. The {{code|@AfterEach}} annotation allows for cleanup after test execution.{{sfn|Gulati|Sharma|2017|loc=Chapter §2 JUnit LifeCycle API|pp=37-40}}

==Integration with other tools==
JUnit 5 integrates a number of tools, such as [[build tool]]s, [[integrated development environment]]s (IDE), [[continuous integration]] (CI) tools and many more.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools|p=99}}

===Build Tools===
{{main article | Build tool }}
JUnit supports [[Apache Ant]], [[Apache Maven]] and [[Gradle]] build tools, which are the most widely used project build tools.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Build Tools|pp=99-117}} Build tools are vital for automating the process of building the project. {{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools|p=99}}

====Ant Extension====
{{main article | Apache Ant }}
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.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Ant|pp=108-112}} Ant centers around the <code>build.xml</code> file, used for configuring the tasks necessary to run a project.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Ant|pp=108-112}} Ant also has an extension called [[Apache Ivy]], which helps deal with dependency resolution. The project dependencies can be declared in the <code>ivy.xml</code> file. Ant can integrate with JUnit 5 by configuring the [[Java code coverage tools]] (JaCoCo), for the <code>ivy.xml</code> file.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Ant|pp=108-112}} The <code>ivy.xml</code> can then be configured with the <code>java-platform-console</code> and <code>junit-platform-runner</code> dependencies to integrate with JUnit 5. {{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Ant Extension|pp=116-117}}

====Maven Extension====
{{main article | Apache Maven}}

In contrast to Ant, Apache Maven, also known as Maven, uses a standardized and unified approach to the build process.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven|pp=104-108}} Maven follows the paradigm of "convention over configuration" for managing its dependencies.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} The Java source code (or "src") can be found under the <code>src/main/java</code> directory, and the test files can be found under the <code>src/test/java</code> directory.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} Maven can be used for any Java Project.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven|pp=104-108}} It uses the [[Project Object Model]] (POM), which is an XML-based approach to configuring the build steps for the project.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven|pp=104-108}} The minimal Maven with the <code>pom.xml</code> build file must contain a list of dependencies and a unique project identifier.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven|pp=104-108}} Maven must be available on the build path to work.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven|pp=104-108}} Maven can integrate with JUnit 5 using the <code>jacoco-maven-plugin</code> [[Plug-in (computing)|plugin]] which supports out-of-box functionality for JUnit 5 tests.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven Extension|p=115}} Different Maven goals can be specified to achieve these tasks.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Maven Extension|p=115}}

====Gradle Extension====
{{main article | Gradle}}

Gradle is a build tool that borrows many concepts from its predecessors, Ant and Maven.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} It uses the {{code|build.gradle}} file to declare the steps required for the project build.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} Unlike Ant and Maven, which are XML-based, Gradle requires the use of [[Apache Groovy]], which is a Java-based programming language.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} Unlike Ant and Maven, Gradle does not require the use of XML.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} Gradle still adheres to Maven's "convention over configuration" approach, and follows the same structure for {{code|src/main/java}} and {{code|src/test/java}} directories.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle|pp=99-103}} Gradle can integrate with JUnit 5 by configuring a plugin {{code|jacoco}} alongside the junit-platform plug-in given by the JUnit 5 team in the build file.{{sfn|Gulati|Sharma|2017|loc=Chapter §6 Integrating Tools - Build Tools - Gradle Extension|pp=113-114}}

==JUnit Extension Model==
JUnit follows the paradigm of preferring extension points over features.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model|p=121}} 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.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model|p=121}} 

In JUnit 4, there are two extension mechanisms: the Runner API and Rule API.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} There were some disadvantages to both the Runner API and the Rule API. 

A major limitation of the Runner API is that developers must implement the entire test lifecycle, even if only a specific phase is required.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} This is too complicated and heavyweight for most use cases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Another major limitation is that only one runner class can be used per test case, which makes runners non-composable.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} For example, Mockito and Parameterized runners cannot be used together within the same test class.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} 

A major limitation of the Rule API is that it cannot control the entire test lifecycle and is therefore unsuitable for certain use cases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Rules are only suitable for operations that need to run before or after test execution.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} Another limitation is that class-level and method-level rules must be defined separately.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 4 Extension Model|pp=121-122}} 

In JUnit 5, the extension API is found within the JUnit Jupiter Engine.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} 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.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} Upon reaching a certain life cycle phase, the Jupiter Engine will invoke all registered extensions for that phase.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}} The developer can hook into five major extension points:{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - JUnit 5 Extension Model|pp=122-124}}
# Test lifecycle callbacks – allow developers to execute code at specific test lifecycle phases.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Test Life Cycle Callbacks|pp=124-126}}
# Test instance post-processing – enables developers to hook into the test instance creation phase using the <code>TestInstancePostProcessor</code> interface.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Test Instance Post-Processing|pp=126-127}}
# Conditional test execution – allows tests to run only if certain conditions are met.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Conditional Test Execution|p=127}}
# Parameter resolution – allows parameters to be injected into test methods or constructors.
# Exception handling – allows developers to modify test behavior in response to exceptions instead of failing the test outright.{{sfn|Gulati|Sharma|2017|loc=Chapter §7 JUnit 5 Extension Model - Exception Handling|p=129}}

==Example of a JUnit test fixture==
A JUnit [[test fixture#Software|test fixture]] is a Java object. Test methods must be annotated by the {{code|@Test}} [[Java annotation|annotation]]. If the situation requires it,<ref>{{cite web
| url=http://c2.com/cgi/wiki?ExpensiveSetUpSmell
| title=Expensive Setup Smell
| publisher=C2 Wiki
| author=Kent Beck
| author-link=Kent Beck
| access-date=2011-11-28}}</ref> it is also possible to define a method to execute before (or after) each (or all) of the test methods with the {{code|@BeforeEach}} (or {{code|@AfterEach}}) and {{code|@BeforeAll}} (or {{code|@AfterAll}}) annotations.<ref name="JUnit 5 User Guide: Writing Tests">{{cite web | url=https://junit.org/junit5/docs/current/user-guide/#writing-tests | title=Writing Tests | website=junit.org | access-date=2021-02-04}}</ref>{{sfn|Gulati|Sharma|2017|loc=Chapter §2 Understanding CoreJunit 5|p=37-40}}

<syntaxhighlight lang=Java>
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 
    }
}
</syntaxhighlight>

==Previous versions of JUnit==
According to Martin Fowler, one of the early adopters of JUnit:<ref>{{Cite web |title=bliki: Xunit |url=https://martinfowler.com/bliki/Xunit.html |access-date=2022-03-07 |website=martinfowler.com}}</ref>
{{Blockquote
|text=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 [[Apache Maven|Maven]] Central repository.<ref name="Maven Central">{{cite web | url=https://mvnrepository.com/artifact/junit/junit/usages | title=JUnit | website=mvnrepository.com | access-date=29 October 2021}}</ref>

In JUnit 4, the annotations for test execution callbacks were {{code|@BeforeClass}}, {{code|@Before}}, {{code|@After}}, and {{code|@AfterClass}}, as opposed to JUnit 5's {{code|@BeforeAll}}, {{code|@BeforeEach}}, {{code|@AfterEach}}, and {{code|@AfterAll}}.<ref name="JUnit 5 User Guide: Writing Tests"/>{{sfn|Gulati|Sharma|2017|loc=Chapter  §2 Understanding CoreJunit 5|p=37-40}}

In JUnit 3, test fixtures had to inherit from {{code|junit.framework.TestCase}}.<ref name="JUnitCookbook">{{cite web
| url=http://junit.sourceforge.net/doc/cookbook/cookbook.htm
| title=JUnit Cookbook
| publisher=junit.sourceforge.net
| author1=Kent Beck
| author2=Erich Gamma
| author-link1=Kent Beck
| author-link2=Erich Gamma
| access-date=2011-05-21
| archive-date=2020-06-15
| archive-url=https://web.archive.org/web/20200615030913/http://junit.sourceforge.net/doc/cookbook/cookbook.htm
| url-status=dead
}}</ref> Additionally, test methods had to be prefixed with 'test'.<ref name="Migrating from JUnit 3 to JUnit 4: Nothing But Good News">{{cite web | url=https://objectcomputing.com/resources/publications/sett/august-2007-migrating-from-junit-3-to-junit-4-nothing-but-good-news | title=Migrating from JUnit 3 to JUnit 4: Nothing But Good News | publisher=Object Computing, Inc. | author1=Charles A. Sharp | date=August 2007 | access-date=2021-02-04}}</ref>

==See also==
{{Portal|Free and open-source software}}
* [[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]]

==Citations==
{{Reflist}}

==References==
* {{cite book | last=Gulati | first=Shekhar | last2=Sharma | first2=Rahul | title=Java Unit Testing with JUnit 5 | publisher=[[Apress]] | publication-place=Berkeley, CA | year=2017 | isbn=978-1-4842-3014-5 | doi=10.1007/978-1-4842-3015-2}}

==External links==
<!-- Please don't add links to non-Java xUnit frameworks here. 
 Instead, add them to http://en.wikipedia.org/wiki/XUnit -->
* {{Official website|https://junit.org}}
* {{cite web |url= http://www.methodsandtools.com/tools/tools.php?junit |title= JUnit - Open Source Java Unit Testing Tool |website= Methods and Tools |first= Axel |last= Irriger }}
* {{cite web |url= http://memorynotfound.com/category/testing/junit |title= JUnit |series= Tutorials |website= Memory Not Found |url-status= live |archive-date= Jan 28, 2015  |archive-url= https://web.archive.org/web/20150128114403/http://memorynotfound.com/category/testing/junit }}


[[Category:Cross-platform software]]
[[Category:Extreme programming]]
[[Category:Free software programmed in Java (programming language)]]
[[Category:Java development tools]]
[[Category:Java platform]]
[[Category:Unit testing frameworks]]
[[Category:Software using the Eclipse Public License]]
[[Category:Articles with example Java code]]