1. Overview
The goal of this document is to provide comprehensive reference documentation for programmers writing tests, extension authors, and engine authors as well as build tool and IDE vendors.
1.1. What is JUnit 5?
Unlike previous versions of JUnit, JUnit 5 is composed of several different modules from three different sub-projects.
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
The JUnit Platform serves as a foundation for launching testing
frameworks on the JVM. It also defines the TestEngine
API for developing a testing
framework that runs on the platform. Furthermore, the platform provides a
Console Launcher to launch the platform from the
command line and build plugins for Gradle and
Maven as well as a
JUnit 4 based Runner for running any TestEngine
on the platform.
JUnit Jupiter is the combination of the new programming model and
extension model for writing tests and extensions in JUnit 5. The Jupiter
sub-project provides a TestEngine
for running Jupiter based tests on the platform.
JUnit Vintage provides a TestEngine
for running JUnit 3 and JUnit 4 based tests on
the platform.
1.2. Supported Java Versions
JUnit 5 requires Java 8 at runtime. However, you can still test code that has been compiled with previous versions of the JDK.
2. Installation
Artifacts for final releases and milestones are deployed to Maven Central.
Snapshot artifacts are deployed to Sonatype’s snapshots repository under /org/junit.
2.1. Dependency Metadata
2.1.1. JUnit Platform
-
Group ID:
org.junit.platform
-
Version:
1.0.0-M1
-
Artifact IDs:
-
junit-platform-commons
-
junit-platform-console
-
junit-platform-engine
-
junit-platform-gradle-plugin
-
junit-platform-launcher
-
junit-platform-runner
-
junit-platform-surefire-provider
-
2.1.2. JUnit Jupiter
-
Group ID:
org.junit.jupiter
-
Version:
5.0.0-M1
-
Artifact IDs:
-
junit-jupiter-api
-
junit-jupiter-engine
-
2.1.3. JUnit Vintage
-
Group ID:
org.junit.vintage
-
Version:
4.12.0-M1
-
Artifact ID:
junit-vintage-engine
2.2. JUnit Jupiter Sample Projects
The junit5-samples
repository hosts a collection of sample
projects based on JUnit Jupiter and JUnit Vintage. You’ll find the respective
build.gradle
and pom.xml
in the projects below.
-
For Gradle, check out the
junit5-gradle-consumer
project. -
For Maven, check out the
junit5-maven-consumer
project.
3. Writing Tests
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
class FirstJUnit5Tests {
@Test
void myFirstTest() {
assertEquals(2, 1 + 1);
}
}
3.1. Annotations
JUnit Jupiter supports the following annotations for configuring tests and extending the framework.
All core annotations are located in the org.junit.jupiter.api
package in the junit-jupiter-api
module.
Annotation | Description |
---|---|
|
Denotes that a method is a test method. Unlike JUnit 4’s |
|
Denotes that a method is a test factory for dynamic tests |
|
Declares a custom display name for the test class or test method |
|
Denotes that the annotated method should be executed before each |
|
Denotes that the annotated method should be executed after each |
|
Denotes that the annotated method should be executed before all |
|
Denotes that the annotated method should be executed after all |
|
Denotes that the annotated class is a nested, non-static test class. Due to restrictions of the Java language, |
|
Used to declare tags for filtering tests, either at the class or method level; analogous to test groups in TestNG or Categories in JUnit 4 |
|
Used to disable a test class or test method; analogous to JUnit 4’s |
|
Used to register custom extensions |
3.1.1. Meta-Annotations and Composed Annotations
JUnit Jupiter annotations can be used as meta-annotations. That means that you can define your own composed annotation that will automatically inherit the semantics of its meta-annotations.
For example, instead of copying and pasting @Tag("fast")
throughout your code base (see
Tagging and Filtering), you can create a custom composed annotation named @Fast
as follows. @Fast
can then be used as a drop-in replacement for @Tag("fast")
.
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.junit.jupiter.api.Tag;
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Tag("fast")
public @interface Fast {
}
3.2. Standard Test Class
import static org.junit.jupiter.api.Assertions.fail;
import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
class StandardTests {
@BeforeAll
static void initAll() {
}
@BeforeEach
void init() {
}
@Test
void succeedingTest() {
}
@Test
void failingTest() {
fail("a failing test");
}
@Test
@Disabled("for demonstration purposes")
void skippedTest() {
// not executed
}
@AfterEach
void tearDown() {
}
@AfterAll
static void tearDownAll() {
}
}
Neither test classes nor test methods need to be public .
|
3.3. Display Names
Test classes and test methods can declare custom display names — with spaces, special characters, and even emojis — that will be displayed by test runners and test reporting.
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
@DisplayName("A special test case")
class DisplayNameDemo {
@Test
@DisplayName("Custom test name containing spaces")
void testWithDisplayNameContainingSpaces() {
}
@Test
@DisplayName("╯°□°)╯")
void testWithDisplayNameContainingSpecialCharacters() {
}
@Test
@DisplayName("😱")
void testWithDisplayNameContainingEmoji() {
}
}
3.4. Assertions
JUnit Jupiter comes with many of the assertion methods that JUnit 4 has and adds a few that
lend themselves well to being used with Java 8 lambdas. All JUnit Jupiter assertions are static
methods in the org.junit.jupiter.Assertions
class.
import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.junit.jupiter.api.Assertions.expectThrows;
import org.junit.jupiter.api.Test;
class AssertionsDemo {
@Test
void standardAssertions() {
assertEquals(2, 2);
assertEquals(4, 4, "The optional assertion message is now the last parameter.");
assertTrue(2 == 2, () -> "Assertion messages can be lazily evaluated -- "
+ "to avoid constructing complex messages unnecessarily.");
}
@Test
void groupedAssertions() {
// In a grouped assertion all assertions are executed, and any
// failures will be reported together.
assertAll("address",
() -> assertEquals("John", address.getFirstName()),
() -> assertEquals("User", address.getLastName())
);
}
@Test
void exceptionTesting() {
Throwable exception = expectThrows(IllegalArgumentException.class, () -> {
throw new IllegalArgumentException("a message");
});
assertEquals("a message", exception.getMessage());
}
}
3.5. Assumptions
JUnit Jupiter comes with a subset of the assumption methods that JUnit 4 provides and adds a
few that lend themselves well to being used with Java 8 lambdas. All JUnit Jupiter assumptions
are static methods in the org.junit.jupiter.Assumptions
class.
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assumptions.assumeTrue;
import static org.junit.jupiter.api.Assumptions.assumingThat;
import org.junit.jupiter.api.Test;
public class AssumptionsDemo {
@Test
void testOnlyOnCiServer() {
assumeTrue("CI".equals(System.getenv("ENV")));
// remainder of test
}
@Test
void testOnlyOnDeveloperWorkstation() {
assumeTrue("DEV".equals(System.getenv("ENV")),
() -> "Aborting test: not on developer workstation");
// remainder of test
}
@Test
void testInAllEnvironments() {
assumingThat("CI".equals(System.getenv("ENV")),
() -> {
// perform these assertions only on the CI server
assertEquals(2, 2);
});
// perform these assertions in all environments
assertEquals("a string", "a string");
}
}
3.6. Disabling Tests
Here’s a disabled test case.
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
@Disabled
class DisabledClassDemo {
@Test
void testWillBeSkipped() {
}
}
And here’s a test case with a disabled test method.
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
class DisabledTestsDemo {
@Disabled
@Test
void testWillBeSkipped() {
}
@Test
void testWillBeExecuted() {
}
}
3.7. Tagging and Filtering
Test classes and methods can be tagged. Those tags can later be used to filter test discovery and execution.
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
@Tag("fast")
@Tag("model")
class TaggingDemo {
@Test
@Tag("taxes")
void testingTaxCalculation() {
}
}
3.8. Nested Tests
Nested tests give the test writer more capabilities to express the relationship among several group of tests. Here’s an elaborate example.
@DisplayName("A stack")
class TestingAStackDemo {
Stack<Object> stack;
boolean isRun = false;
@Test
@DisplayName("is instantiated with new Stack()")
void isInstantiatedWithNew() {
new Stack<Object>();
}
@Nested
@DisplayName("when new")
class WhenNew {
@BeforeEach
void init() {
stack = new Stack<Object>();
}
@Test
@DisplayName("is empty")
void isEmpty() {
Assertions.assertTrue(stack.isEmpty());
}
@Test
@DisplayName("throws EmptyStackException when popped")
void throwsExceptionWhenPopped() {
Assertions.expectThrows(EmptyStackException.class, () -> stack.pop());
}
@Test
@DisplayName("throws EmptyStackException when peeked")
void throwsExceptionWhenPeeked() {
Assertions.expectThrows(EmptyStackException.class, () -> stack.peek());
}
@Nested
@DisplayName("after pushing an element")
class AfterPushing {
String anElement = "an element";
@BeforeEach
void init() {
stack.push(anElement);
}
@Test
@DisplayName("it is no longer empty")
void isEmpty() {
Assertions.assertFalse(stack.isEmpty());
}
@Test
@DisplayName("returns the element when popped and is empty")
void returnElementWhenPopped() {
Assertions.assertEquals(anElement, stack.pop());
Assertions.assertTrue(stack.isEmpty());
}
@Test
@DisplayName("returns the element when peeked but remains not empty")
void returnElementWhenPeeked() {
Assertions.assertEquals(anElement, stack.peek());
Assertions.assertFalse(stack.isEmpty());
}
}
}
}
Only non-static nested classes (i.e. inner classes) can serve as
@Nested tests. Nesting can be arbitrarily deep, and those inner classes are considered
to be full members of the test class family with one exception: @BeforeAll and
@AfterAll do not work, because Java does not allow static members in inner classes.
|
3.9. Dependency Injection for Constructors and Methods
In all prior JUnit versions, test constructors or methods were not allowed to have
parameters (at least not with the standard Runner
implementations). As one of the major
changes in JUnit Jupiter, both test constructors and methods are now permitted to have
parameters. This allows for greater flexibility and enables Dependency Injection for
constructors and methods.
ParameterResolver
defines the API for test extensions that wish to dynamically
resolve parameters at runtime. If a test constructor or a @Test
, @TestFactory
,
@BeforeEach
, @AfterEach
, @BeforeAll
, or @AfterAll
method accepts a parameter, the
parameter must be resolved at runtime by a registered ParameterResolver
.
There are currently two built-in resolvers that are registered automatically.
-
TestInfoParameterResolver
: if a method parameter is of typeTestInfo
, theTestInfoParameterResolver
will supply an instance ofTestInfo
corresponding to the current test as the value for the parameter. TheTestInfo
can then be used to retrieve information about the current test such as the test’s display name, the test class, the test method, or associated tags. The display name is either a technical name, such as the name of the test class or test method, or a custom name configured via@DisplayName
.TestInfo
acts as a drop-in replacement for theTestName
rule from JUnit 4. Here is an example of its usage.
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;
class TestInfoDemo {
@BeforeEach
void init(TestInfo testInfo) {
String displayName = testInfo.getDisplayName();
assertTrue(displayName.equals("TEST 1") || displayName.equals("test2()"));
}
@Test
@DisplayName("TEST 1")
@Tag("my tag")
void test1(TestInfo testInfo) {
assertEquals("TEST 1", testInfo.getDisplayName());
assertTrue(testInfo.getTags().contains("my tag"));
}
@Test
void test2() {
}
}
-
TestReporterParameterResolver
: if a method parameter is of typeTestReporter
, theTestReporterParameterResolver
will supply an instance ofTestReporter
. TheTestReporter
can be used to publish additional data about the current test run. The data can be consumed throughTestExecutionListener.reportingEntryPublished()
and thus be viewed by IDEs or included in reports.In JUnit Jupiter you should use
TestReporter
where you used to print information tostdout
orstderr
in JUnit 4. Using@RunWith(JUnitPlatform.class)
will even output all reported entries tostdout
.
import java.util.HashMap;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestReporter;
class TestReporterDemo {
@Test
void reportSingleValue(TestReporter testReporter) {
testReporter.publishEntry("a key", "a value");
}
@Test
void reportSeveralValues(TestReporter testReporter) {
HashMap<String, String> values = new HashMap<>();
values.put("user name", "dk38");
values.put("award year", "1974");
testReporter.publishEntry(values);
}
}
Other parameter resolvers must be explicitly enabled by registering appropriate
extensions via @ExtendWith .
|
Check out the MockitoExtension
for an example of a custom ParameterResolver
.
While not intended to be production-ready, it demonstrates the simplicity and
expressiveness of both the extension model and the parameter resolution process.
MyMockitoTest
demonstrates how to inject Mockito mocks into @BeforeEach
and @Test
methods.
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import com.example.Person;
import com.example.mockito.MockitoExtension;
@ExtendWith(MockitoExtension.class)
class MyMockitoTest {
@BeforeEach
void init(@Mock Person person) {
when(person.getName()).thenReturn("Dilbert");
}
@Test
void simpleTestWithInjectedMock(@Mock Person person) {
assertEquals("Dilbert", person.getName());
}
}
3.10. Interface Default Methods
JUnit Jupiter allows @Test
, @TestFactory
, @BeforeEach
, and @AfterEach
to be declared on
interface default methods. One possible application of this feature is to write tests for
interface contracts. For example, you can write tests for how implementations of
Object.equals
or Comparable.compareTo
should behave as follows.
public interface Testable<T> {
T createValue();
}
public interface EqualsContract<T> extends Testable<T> {
T createNotEqualValue();
@Test
default void valueEqualsItself() {
T value = createValue();
assertEquals(value, value);
}
@Test
default void valueDoesNotEqualNull() {
T value = createValue();
assertFalse(value.equals(null));
}
@Test
default void valueDoesNotEqualDifferentValue() {
T value = createValue();
T differentValue = createNotEqualValue();
assertNotEquals(value, differentValue);
assertNotEquals(differentValue, value);
}
}
public interface ComparableContract<T extends Comparable<T>> extends Testable<T> {
T createSmallerValue();
@Test
default void returnsZeroWhenComparedToItself() {
T value = createValue();
assertEquals(0, value.compareTo(value));
}
@Test
default void returnsPositiveNumberComparedToSmallerValue() {
T value = createValue();
T smallerValue = createSmallerValue();
assertTrue(value.compareTo(smallerValue) > 0);
}
@Test
default void returnsNegativeNumberComparedToSmallerValue() {
T value = createValue();
T smallerValue = createSmallerValue();
assertTrue(smallerValue.compareTo(value) < 0);
}
}
In your test class you can then implement both contract interfaces thereby inheriting the corresponding tests. Of course you’ll have to implement the abstract methods.
class StringTests implements ComparableContract<String>, EqualsContract<String> {
@Override
public String createValue() {
return "foo";
}
@Override
public String createSmallerValue() {
return "bar"; // 'b' < 'f' in "foo"
}
@Override
public String createNotEqualValue() {
return "baz";
}
}
The above tests are merely meant as examples and therefore not complete.
3.11. Dynamic Tests
The standard @Test
annotation in JUnit Jupiter described in Annotations
is very similar to the @Test
annotation in JUnit 4.
Both describe methods that implement test cases.
These test cases are static in the sense that they are fully specified at compile-time,
and their behavior cannot be changed by anything happening at run-time.
Assumptions provide a basic form of dynamic behavior but are intentionally rather limited in their expressiveness.
In addition to these standard tests a completely new kind of test programming model has been introduced in JUnit Jupiter.
This new kind of test is a dynamic test which is generated at run-time by a factory method
that is annotated with @TestFactory
.
In contrast to @Test
methods, a @TestFactory
method is not itself a test case but rather a factory for test cases.
Thus, a dynamic test is the product of a factory.
Technically speaking, a @TestFactory
method must return a Stream
,
Collection
, Iterable
, or Iterator
of DynamicTest
instances.
These DynamicTest
instances will then be executed lazily,
enabling dynamic and even non-deterministic generation of test cases.
As with @Test
methods, @TestFactory
methods must not be private
or static
and may optionally declare parameters to be resolved by ParameterResolvers
.
A DynamicTest
is a test case generated at runtime.
It is composed of a display name and an Executable
. Executable
is a @FunctionalInterface
which means that the implementations of dynamic tests can be provided as lambda expressions
or method references.
Dynamic Test Lifecycle
The execution lifecycle of a dynamic test is quite different than it is for a
standard @Test case. Specifically, there are not any lifecycle callbacks for dynamic
tests. This means that @BeforeEach and @AfterEach methods and their corresponding
extension callbacks are not executed for dynamic tests. In other words, if you access
fields from the test instance within a lambda expression for a dynamic test, those fields
will not be reset by callback methods or extensions between the execution of dynamic
tests generated by the same @TestFactory method.
|
As of JUnit Jupiter 5.0.0-M1, dynamic tests must always be created by factory methods; however, this might be complemented by a registration facility in a later release.
3.11.1. Dynamic Test Examples
The following DynamicTestsDemo
class demonstrates several examples of test factories and dynamic tests.
The first method returns an invalid return type. Since an invalid return type cannot be
detected at compile-time, a JUnitException
is thrown when it is detected at run-time.
The next five methods are very simple examples that demonstrate the generation of a
Collection
, Iterable
, Iterator
, or Stream
of DynamicTest
instances.
Most of these examples do not really exhibit dynamic behavior
but merely demonstrate the supported return types in principle.
However, dynamicTestsFromStream()
and dynamicTestsFromIntStream()
demonstrate how
easy it is to generate dynamic tests for a given set of strings or a range of input numbers.
The last method is truly dynamic in nature.
generateRandomNumberOfTests()
implements an Iterator
that generates random numbers, a
display name generator, and a test executor and then provides all three to DynamicTest.stream()
.
Although the non-deterministic behavior of generateRandomNumberOfTests()
is of course in conflict with
test repeatability and should thus be used with care, it serves to demonstrate the expressiveness
and power of dynamic tests.
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.junit.jupiter.api.DynamicTest.dynamicTest;
import java.util.Arrays;
import java.util.Collection;
import java.util.Iterator;
import java.util.List;
import java.util.Random;
import java.util.function.Consumer;
import java.util.function.Function;
import java.util.stream.IntStream;
import java.util.stream.Stream;
import org.junit.jupiter.api.DynamicTest;
import org.junit.jupiter.api.Tag;
import org.junit.jupiter.api.TestFactory;
class DynamicTestsDemo {
// This will result in a JUnitException!
@TestFactory
List<String> dynamicTestsWithInvalidReturnType() {
return Arrays.asList("Hello");
}
@TestFactory
Collection<DynamicTest> dynamicTestsFromCollection() {
return Arrays.asList(
dynamicTest("1st dynamic test", () -> assertTrue(true)),
dynamicTest("2nd dynamic test", () -> assertEquals(4, 2 * 2))
);
}
@TestFactory
Iterable<DynamicTest> dynamicTestsFromIterable() {
return Arrays.asList(
dynamicTest("3rd dynamic test", () -> assertTrue(true)),
dynamicTest("4th dynamic test", () -> assertEquals(4, 2 * 2))
);
}
@TestFactory
Iterator<DynamicTest> dynamicTestsFromIterator() {
return Arrays.asList(
dynamicTest("5th dynamic test", () -> assertTrue(true)),
dynamicTest("6th dynamic test", () -> assertEquals(4, 2 * 2))
).iterator();
}
@TestFactory
Stream<DynamicTest> dynamicTestsFromStream() {
return Stream.of("A", "B", "C").map(
str -> dynamicTest("test" + str, () -> { /* ... */ }));
}
@TestFactory
Stream<DynamicTest> dynamicTestsFromIntStream() {
// Generates tests for the first 10 even integers.
return IntStream.iterate(0, n -> n + 2).limit(10).mapToObj(
n -> dynamicTest("test" + n, () -> assertTrue(n % 2 == 0)));
}
@TestFactory
Stream<DynamicTest> generateRandomNumberOfTests() {
// Generates random positive integers between 0 and 100 until
// a number evenly divisible by 7 is encountered.
Iterator<Integer> inputGenerator = new Iterator<Integer>() {
Random random = new Random();
int current;
@Override
public boolean hasNext() {
current = random.nextInt(100);
return current % 7 != 0;
}
@Override
public Integer next() {
return current;
}
};
// Generates display names like: input:5, input:37, input:85, etc.
Function<Integer, String> displayNameGenerator = (input) -> "input:" + input;
// Executes tests based on the current input value.
Consumer<Integer> testExecutor = (input) -> assertTrue(input % 7 != 0);
// Returns a stream of dynamic tests.
return DynamicTest.stream(inputGenerator, displayNameGenerator, testExecutor);
}
}
4. Running Tests
4.1. IDE Support
At the time of this writing there is no direct support for running tests on the JUnit Platform within IDEs. However, the JUnit team provides two intermediate solutions so that you can go ahead and try out JUnit 5 within your IDE today. You can use the Console Launcher manually or execute tests with a JUnit 4 based Runner.
4.2. Build Support
4.2.1. Gradle
The JUnit team has developed a very basic Gradle plugin that allows you to run any kind
of test that is supported by a TestEngine
(e.g., JUnit 3, JUnit 4, JUnit Jupiter, Specsy,
etc.). See build.gradle
in the junit5-gradle-consumer
project for an example of the
plugin in action.
Enabling the JUnit Gradle Plugin
To use the JUnit Gradle plugin, you first need to make sure that you are running Gradle
2.5 or higher. Once you’ve done that, you can configure build.gradle
as follows.
buildscript {
repositories {
mavenCentral()
// The following is only necessary if you want to use SNAPSHOT releases.
// maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}
dependencies {
classpath 'org.junit.platform:junit-platform-gradle-plugin:1.0.0-M1'
}
}
apply plugin: 'org.junit.platform.gradle.plugin'
Configuring the JUnit Gradle Plugin
Once the JUnit Gradle plugin has been applied, you can configure it as follows.
These options are very likely to change as we continue to work towards the final release. |
junitPlatform {
platformVersion 1.0
logManager 'org.apache.logging.log4j.jul.LogManager'
reportsDir "build/test-results/junit-platform" // this is the default
// enableStandardTestTask true
engines {
include 'junit-jupiter'
// exclude 'junit-vintage'
}
tags {
include 'fast', 'smoke'
// exclude 'slow', 'ci'
}
includeClassNamePattern '.*Tests'
}
Setting logManager
instructs the JUnit Gradle plugin to set the
java.util.logging.manager
system property to the supplied fully qualified class name of
the java.util.logging.LogManager
implementation to use. The above example demonstrates
how to configure log4j as the LogManager
.
By default, the JUnit Gradle plugin disables the standard Gradle test
task, but this be
overridden via the enableStandardTestTask
flag.
By default all engines and tags are included in the test plan. If you supply a Test
Engine ID via engines {include …}
or engines {exclude …}
, the JUnit Gradle
plugin will only run tests for the desired test engines. Similarly, if you supply a tag
via tags {include …}
or tags {exclude …}
, the JUnit Gradle plugin will only run
tests that are tagged accordingly (e.g., via the @Tag
annotation for JUnit Jupiter based
tests).
Configuring Test Engines
In order to have the JUnit Gradle plugin run any tests at all, a TestEngine
implementation must be on the classpath.
To configure support for JUnit Jupiter based tests, configure a testCompile
dependency on the
JUnit Jupiter API and a testRuntime
dependency on the JUnit Jupiter TestEngine
implementation
similar to the following.
dependencies {
testCompile("org.junit.jupiter:junit-jupiter-api:5.0.0-M1")
testRuntime("org.junit.jupiter:junit-jupiter-engine:5.0.0-M1")
}
The JUnit Gradle plugin can run JUnit 4 based tests as long as you configure a
testCompile
dependency on JUnit 4 and a testRuntime
dependency on the JUnit 4
TestEngine implementation similar to the following.
dependencies {
testCompile("junit:junit:4.12")
testRuntime("org.junit.vintage:junit-vintage-engine:4.12.0-M1")
}
Using the JUnit Gradle Plugin
Once the JUnit Gradle plugin has been applied and configured, you have a new
junitPlatformTest
task at your disposal.
Invoking gradlew clean junitPlatformTest
(or gradlew clean test
) from the command
line will execute all tests within the project whose class names match the regular
expression supplied via includeClassNamePattern
.
Executing the junitPlatformTest
task in the junit5-gradle-consumer
project results
in output similar to the following:
:junitPlatformTest Test run finished after 93 ms [ 3 tests found ] [ 1 tests skipped ] [ 2 tests started ] [ 0 tests aborted ] [ 2 tests successful] [ 0 tests failed ] BUILD SUCCESSFUL
If a test fails, the build will fail with output similar to the following:
:junitPlatformTest Test failures (1): JUnit Jupiter:SecondTest:mySecondTest() JavaMethodSource [javaClass = 'com.example.project.SecondTest', javaMethodName = 'mySecondTest', javaMethodParameterTypes = ''] => Exception: 2 is not equal to 1 ==> expected: <2> but was: <1> Test run finished after 99 ms [ 3 tests found ] [ 0 tests skipped ] [ 3 tests started ] [ 0 tests aborted ] [ 2 tests successful] [ 1 tests failed ] :junitPlatformTest FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':junitPlatformTest'. > Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1
The exit value is 1 if any tests failed; otherwise, it is 0 .
|
Current Limitations of the JUnit Gradle Plugin
The results of any tests run via the JUnit Gradle plugin will not be included
in the standard test report generated by Gradle; however, the test results can
be aggregated. See the reportsDir property of the plugin.
|
4.2.2. Maven
The JUnit team has developed a very basic provider for Maven Surefire that lets you run
JUnit 4 and JUnit Jupiter tests via mvn test
. The pom.xml
file in the
junit5-maven-consumer
project demonstrates how to use it and can serve as a starting
point.
...
<build>
<plugins>
...
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19</version>
<dependencies>
<dependency>
<groupId>org.junit</groupId>
<artifactId>junit-platform-surefire-provider</artifactId>
<version>1.0.0-M1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
...
4.3. Console Launcher
The ConsoleLauncher
is a command-line Java application that lets you launch
the JUnit Platform from the console. For example, it can be used to run JUnit
Vintage and JUnit Jupiter tests and print test execution results to the console.
Here’s an example of its output:
Test execution started. Number of static tests: 2 Engine started: junit-jupiter Test started: My 1st JUnit 5 test! 😎 [junit-jupiter:com.example.project.FirstTest#myFirstTest(java.lang.String)] Test succeeded: My 1st JUnit 5 test! 😎 [junit-jupiter:com.example.project.FirstTest#myFirstTest(java.lang.String)] Test skipped: mySecondTest [junit-jupiter:com.example.project.SecondTest#mySecondTest()] => Exception: Skipped test method [void com.example.project.SecondTest.mySecondTest()] due to failed condition Engine finished: junit-jupiter Test execution finished. Test run finished after 29 ms [ 2 tests found ] [ 1 tests started ] [ 1 tests skipped ] [ 0 tests aborted ] [ 1 tests successful] [ 0 tests failed ]
Exit Code
The ConsoleLauncher exits with a status code of 1 if any tests failed. Otherwise
the exit code is 0 .
|
4.3.1. Options
These options are very likely to change as we continue to work towards the final release. |
Non-option arguments: Test classes, methods, or packages to execute. If --all|-a has been provided, arguments can list all classpath roots that should be considered for test scanning, or none if the full classpath should be scanned. Option Description ------ ----------- -a, --all Run all tests -p, --classpath Provide additional classpath entries -- for example, for adding engines and their dependencies. -n, --include-classname Provide a regular expression to include only classes whose fully qualified names match. By default any class name is accepted, and thus all classes with tests are included. -t, --include-tag Provide a tag to be included in the test run. This option can be repeated. -T, --exclude-tag Provide a tag to be excluded from the test run. This option can be repeated. -e, --include-engine Provide the ID of an engine to be included in the test run. This option can be repeated. -E, --exclude-engine Provide the ID of an engine to be excluded from the test run. This option can be repeated. -r, --xml-reports-dir Enable XML report output into a specified local directory (will be created if it does not exist). -C, --disable-ansi-colors Disable colored output (not supported by all terminals). -D, --hide-details Hide details while tests are being executed. Only show the summary and test failures. -h, --help Display help information.
4.4. Using JUnit 4 to Run the JUnit Platform
The JUnitPlatform
runner is a JUnit 4 based Runner
which enables you to run any test
whose programming model is supported on the JUnit Platform in a JUnit 4 environment — for example, a JUnit Jupiter test class.
Annotating a class with @RunWith(JUnitPlatform.class)
allows it to be run with IDEs and
build systems that support JUnit 4 but do not yet support the JUnit Platform directly.
Since the JUnit Platform has features that JUnit 4 does not have, the runner is
only able to support a subset of the JUnit Platform functionality, especially with regard
to reporting (see Display Names vs. Technical Names). But for the
time being the JUnitPlatform runner is an easy way to get started.
|
4.4.1. Setup
You need the following artifacts and their dependencies on the classpath. See Dependency Metadata for details regarding group IDs, artifact IDs, and versions.
-
junit-jupiter-api
in test scope: API for writing tests, including@Test
, etc. -
junit-platform-runner
in test scope: location of theJUnitPlatform
runner -
junit-jupiter-engine
in test runtime scope: implementation of the Engine API for JUnit Jupiter
4.4.2. Display Names vs. Technical Names
By default, display names will be used for test artifacts; however, when the
JUnitPlatform
runner is used to execute tests with a build tool such as Gradle or
Maven, the generated test report often needs to include the technical names of test
artifacts — for example, fully qualified class names — instead of shorter display names
like the simple name of a test class or a custom display name containing special
characters. To enable technical names for reporting purposes, simply declare the
@UseTechnicalNames
annotation alongside @RunWith(JUnitPlatform.class)
.
4.4.3. Single Test Class
One way to use the JUnitPlatform
runner is to annotate a test class with
@RunWith(JUnitPlatform.class)
directly. Please note that the test methods in the
following example are annotated with org.junit.jupiter.api.Test
(JUnit Jupiter), not
org.junit.Test
(JUnit Vintage). Moreover, in this case the test class must be public
;
otherwise, IDEs won’t recognize it as a test class.
import static org.junit.jupiter.api.Assertions.fail;
import org.junit.jupiter.api.Test;
import org.junit.platform.runner.JUnitPlatform;
import org.junit.runner.RunWith;
@RunWith(JUnitPlatform.class)
public class JUnit4ClassDemo {
@Test
void succeedingTest() {
/* no-op */
}
@Test
void failingTest() {
fail("Failing for failing's sake.");
}
}
4.4.4. Test Suite
If you have multiple test classes you can create a test suite as can be seen in the following example.
import org.junit.platform.runner.JUnitPlatform;
import org.junit.platform.runner.SelectPackages;
import org.junit.runner.RunWith;
@RunWith(JUnitPlatform.class)
@SelectPackages("example")
public class JUnit4SuiteDemo {
}
The JUnit4SuiteDemo
will discover and run all tests in the example
package
and its subpackages.
Additional Configuration Options
There are more configuration options for discovering and filtering tests than just
@SelectPackages . Please consult the
Javadoc for further
details.
|
5. Extension Model
5.1. Overview
In contrast to the competing Runner
, @Rule
, and @ClassRule
extension points in
JUnit 4, the JUnit Jupiter extension model consists of a single, coherent concept: the
Extension
API. Note, however, that Extension
itself is just a marker interface.
5.2. Registering Extensions
Extensions can be registered declaratively via @ExtendWith
.
Registered extensions are inherited within test class hierarchies. |
5.2.1. Declarative Extension Registration
Developers can register one or more extensions declaratively by annotating a test
class, test method, or custom composed annotation with
@ExtendWith(…)
and supplying class references for the extensions to register. For
example, to register a custom MockitoExtension
for all tests in a particular class and
its subclasses, you would annotate the test class as follows.
@ExtendWith(MockitoExtension.class)
class MockTests {
// ...
}
Multiple extensions can be registered together like this:
@ExtendWith({ FooExtension.class, BarExtension.class })
class MyTestsV1 {
// ...
}
As an alternative, multiple extensions can be registered separately like this:
@ExtendWith(FooExtension.class)
@ExtendWith(BarExtension.class)
class MyTestsV2 {
// ...
}
The execution of tests in both MyTestsV1
and MyTestsV2
will be extended by the
FooExtension
and BarExtension
, in exactly that order.
5.3. Conditional Test Execution
ContainerExecutionCondition
and TestExecutionCondition
define the Extension
APIs for programmatic, conditional test execution.
A ContainerExecutionCondition
is evaluated to determine if all tests in a given
container (e.g., a test class) should be executed based on the supplied
ContainerExtensionContext
. Similarly, a TestExecutionCondition
is evaluated to
determine if a given test method should be executed based on the supplied
TestExtensionContext
.
See the source code of DisabledCondition
and @Disabled
for concrete examples.
5.3.1. Deactivating Conditions
Sometimes it can be useful to run a test suite without certain conditions being active.
For example, you may wish to run tests even if they are annotated with @Disabled
in
order to see if they are still broken. To do this, simply provide a pattern for the
junit.conditions.deactivate
configuration key to specify which conditions should be
deactivated (i.e., not evaluated) for the current test run. The pattern can be supplied
as a JVM system property or as a configuration parameter in the LauncherDiscoveryRequest
that is passed to the Launcher
.
For example, to deactivate JUnit’s @Disabled
condition, you can start your JVM with
the following system property.
-Djunit.conditions.deactivate=org.junit.*DisabledCondition
Pattern Matching Syntax
If the junit.conditions.deactivate
pattern consists solely of an asterisk (*
), all
conditions will be deactivated. Otherwise, the pattern will be used to match against the
fully qualified class name (FQCN) of each registered condition. Any dot (.
) in the
pattern will match against a dot (.
) or a dollar sign ($
) in the FQCN. Any asterisk
(*
) will match against one or more characters in the FQCN. All other characters in the
pattern will be matched one-to-one against the FQCN.
Examples:
-
*
: deactivates all conditions. -
org.junit.*
: deactivates every condition under theorg.junit
base package and any of its subpackages. -
*.MyCondition
: deactivates every condition whose simple class name is exactlyMyCondition
. -
*System*
: deactivates every condition whose simple class name containsSystem
. -
org.example.MyCondition
: deactivates the condition whose FQCN is exactlyorg.example.MyCondition
.
5.4. Test Instance Post-processing
TestInstancePostProcessor
defines the API for Extensions
that wish to post
process test instances.
Common use cases include injecting dependencies into the test instance, invoking custom initialization methods on the test instance, etc.
For concrete examples, consult the source code for the MockitoExtension
and the
SpringExtension
.
5.5. Parameter Resolution
ParameterResolver
defines the Extension
API for dynamically resolving parameters at
runtime.
If a test constructor or a @Test
, @TestFactory
, @BeforeEach
, @AfterEach
,
@BeforeAll
, or @AfterAll
method accepts a parameter, the parameter must be resolved
at runtime by a ParameterResolver
. A ParameterResolver
can either be built-in (see
TestInfoParameterResolver
) or registered by the user.
Generally speaking, parameters may be resolved by name, type, annotation, or any
combination thereof. For concrete examples, consult the source code for
CustomTypeParameterResolver
and CustomAnnotationParameterResolver
.
5.6. Test Lifecycle Callbacks
The following interfaces define the APIs for extending tests at various points in the
test execution lifecycle. Consult the following sections for examples and the Javadoc for
each of these interfaces in the org.junit.jupiter.api.extension
package for further details.
Implementing Multiple Extension APIs
Extension developers may choose to implement any number of these interfaces
within a single extension. Consult the source code of the SpringExtension for a
concrete example.
|
5.6.1. Before and After Test Execution Callbacks
BeforeTestExecutionCallback
and AfterTestExecutionCallback
define the APIs for
Extensions
that wish to add behavior that will be executed immediately before and
immediately after a test method is executed, respectively. As such, these callbacks are
well suited for timing, tracing, and similar use cases. If you need to implement
callbacks that are invoked around @BeforeEach
and @AfterEach
methods, implement
BeforeEachCallback
and AfterEachCallback
instead.
The following example shows how to use these callbacks to calculate and log the execution
time of a test method. TimingExtension
implements both BeforeTestExecutionCallback
and AfterTestExecutionCallback
in order to time and log the test execution.
import java.lang.reflect.Method;
import java.util.logging.Logger;
import org.junit.jupiter.api.extension.AfterTestExecutionCallback;
import org.junit.jupiter.api.extension.BeforeTestExecutionCallback;
import org.junit.jupiter.api.extension.ExtensionContext.Namespace;
import org.junit.jupiter.api.extension.ExtensionContext.Store;
import org.junit.jupiter.api.extension.TestExtensionContext;
public class TimingExtension implements BeforeTestExecutionCallback, AfterTestExecutionCallback {
private static final Logger LOG = Logger.getLogger(TimingExtension.class.getName());
@Override
public void beforeTestExecution(TestExtensionContext context) throws Exception {
getStore(context).put(context.getTestMethod().get(), System.currentTimeMillis());
}
@Override
public void afterTestExecution(TestExtensionContext context) throws Exception {
Method testMethod = context.getTestMethod().get();
long start = getStore(context).remove(testMethod, long.class);
long duration = System.currentTimeMillis() - start;
LOG.info(() -> String.format("Method [%s] took %s ms.", testMethod.getName(), duration));
}
private Store getStore(TestExtensionContext context) {
return context.getStore(Namespace.create(getClass(), context));
}
}
Since the TimingExtensionTests
class registers the TimingExtension
via @ExtendWith
,
its tests will have this timing applied when they execute.
@ExtendWith(TimingExtension.class)
class TimingExtensionTests {
@Test
void sleep20ms() throws Exception {
Thread.sleep(20);
}
@Test
void sleep50ms() throws Exception {
Thread.sleep(50);
}
}
The following is an example of the logging produced when TimingExtensionTests
is run.
INFO: Method [sleep20ms] took 24 ms. INFO: Method [sleep50ms] took 53 ms.
5.7. Exception Handling
TestExecutionExceptionHandler
defines the API for Extensions
that wish to handle
exceptions thrown during test execution.
The following example shows an extension which will swallow all instances of IOException
but rethrow any other type of exception.
public class IgnoreIOExceptionExtension implements TestExecutionExceptionHandler {
@Override
public void handleTestExecutionException(TestExtensionContext context, Throwable throwable)
throws Throwable {
if (throwable instanceof IOException) {
return;
}
throw throwable;
}
}
5.8. Keeping State in Extensions
Usually, an extension is instantiated only once. So the question becomes relevant: How do
you keep the state from one invocation of an extension to the next? The
ExtensionContext
API provides a Store
exactly for this purpose. Consult the
corresponding Javadoc for details.
6. Migrating from JUnit 4
Although the JUnit Jupiter programming model and extension model will not support JUnit 4
features such as Rules
and Runners
, it is not expected that source code maintainers
will need to update all of their existing tests, test extensions, and custom build test
infrastructure to migrate to JUnit Jupiter.
Instead, JUnit provides a gentle migration path via a JUnit Vintage test engine which
allows existing tests based on JUnit 3 and JUnit 4 to be executed using the JUnit
Platform infrastructure. Since all classes and annotations specific to JUnit Jupiter
reside under a new org.junit.jupiter
base package, having both JUnit 4 and JUnit
Jupiter in the classpath does not lead to any conflicts. It is therefore safe to maintain
existing JUnit 4 tests alongside JUnit Jupiter tests. Furthermore, since the JUnit team
will continue to provide maintenance and bug fix releases for the JUnit 4.x baseline,
developers have plenty of time to migrate to JUnit Jupiter on their own schedule.
6.1. Running JUnit 4 Tests on the JUnit Platform
Just make sure that the junit-vintage-engine
artifact is in your test runtime path. In that
case JUnit 3 and JUnit 4 tests will automatically be picked up by the JUnit Platform launcher.
See the example projects in the junit5-samples
repository to
find out how this is done with Gradle and Maven.
6.2. Migration Tips
The following are things you have to watch out for when migrating existing JUnit 4 tests to JUnit Jupiter.
-
Annotations reside in the
org.junit.jupiter.api
package. -
Assertions reside in
org.junit.jupiter.api.Assertions
. -
Assumptions reside in
org.junit.jupiter.api.Assumptions
. -
@Before
and@After
no longer exist; use@BeforeEach
and@AfterEach
instead. -
@BeforeClass
and@AfterClass
no longer exist; use@BeforeAll
and@AfterAll
instead. -
@Ignore
no longer exists: use@Disabled
instead. -
@Category
no longer exists; use@Tag
instead. -
@RunWith
no longer exists; superseded by@ExtendWith
. -
@Rule
and@ClassRule
no longer exist; superseded by@ExtendWith
.
7. Advanced Topics
7.1. JUnit Platform Launcher API
One of the prominent goals of JUnit 5 is to make the interface between JUnit and its programmatic clients – build tools and IDEs – more powerful and stable. The purpose is to decouple the internals of discovering and executing tests from all the filtering and configuration that’s necessary from the outside.
JUnit 5 introduces the concept of a Launcher
that can be used to discover, filter, and
execute tests. Moreover, third party test libraries – like Spock, Cucumber, and FitNesse
– can plug into the JUnit Platform’s launching infrastructure by providing a custom
TestEngine
.
The launching API is in the junit-platform-launcher
module.
An example consumer of the launching API is the ConsoleLauncher
in the
junit-platform-console
project.
7.1.1. Discovering Tests
Introducing test discovery as a dedicated feature of the platform itself will (hopefully) free IDEs and build tools from most of the difficulties they had to go through to identify test classes and test methods in the past.
Usage Example:
import static org.junit.platform.engine.discovery.ClassFilter.includeClassNamePattern;
import static org.junit.platform.engine.discovery.DiscoverySelectors.selectClass;
import static org.junit.platform.engine.discovery.DiscoverySelectors.selectPackage;
import org.junit.jupiter.api.Test;
import org.junit.platform.launcher.Launcher;
import org.junit.platform.launcher.LauncherDiscoveryRequest;
import org.junit.platform.launcher.TestExecutionListener;
import org.junit.platform.launcher.TestPlan;
import org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder;
import org.junit.platform.launcher.core.LauncherFactory;
import org.junit.platform.launcher.listeners.SummaryGeneratingListener;
LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
.selectors(
selectPackage("com.example.mytests"),
selectClass(MyTestClass.class)
)
.filters(includeClassNamePattern(".*Test"))
.build();
TestPlan plan = LauncherFactory.create().discover(request);
There’s currently the possibility to search for classes, methods, all classes in a package, or even all tests in the classpath. Discovery takes place across all participating test engines.
The resulting test plan is basically a hierarchical (and read-only) description of all
engines, classes, and test methods that fit the specification
object. The client can
traverse the tree, retrieve details about a node, and get a link to the original source
(like class, method, or file position). Every node in the test plan tree has a unique
ID that can be used to invoke a particular test or group of tests.
7.1.2. Executing Tests
There are two ways to execute tests. Clients can either use the same test specification
object as in the discovery phase, or – to speed things up a bit – pass in the prepared
TestPlan
object from a previous discovery step. Test progress and result reporting can
be achieved through a TestExecutionListener
:
LauncherDiscoveryRequest request = LauncherDiscoveryRequestBuilder.request()
.selectors(
selectPackage("com.example.mytests"),
selectClass(MyTestClass.class)
)
.filters(includeClassNamePattern(".*Test"))
.build();
Launcher launcher = LauncherFactory.create();
// Register a listener of your choice
TestExecutionListener listener = new SummaryGeneratingListener();
launcher.registerTestExecutionListeners(listener);
launcher.execute(request);
There’s currently no result object, but you can easily use a listener to aggregate the
final results in an object of your own. For an example see the
SummaryGeneratingListener
.
7.1.3. Plugging in Your Own Test Engine
JUnit currently provides two TestEngine
implementations out of the box:
-
junit-jupiter-engine
: The core of JUnit Jupiter. -
junit-vintage-engine
: A thin layer on top of JUnit 4 to allow running vintage tests with the launcher infrastructure.
Third parties may also contribute their own TestEngine
by implementing the interfaces
in the junit-platform-engine module and registering their engine. Engine registration
is currently supported via Java’s java.util.ServiceLoader
mechanism. For example, the
junit-jupiter-engine
module registers its org.junit.jupiter.engine.JupiterTestEngine
in a file named org.junit.platform.engine.TestEngine
within the /META-INF/services
in
the junit-jupiter-engine
JAR.
8. API Evolution
One of the major goals of JUnit 5 is to improve maintainers' capabilities to evolve JUnit despite its being used in many projects. With JUnit 4 a lot of stuff that was originally added as an internal construct only got used by external extension writers and tool builders. That made changing JUnit 4 especially difficult and sometimes impossible.
That’s why JUnit 5 introduces a defined lifecycle for all publicly available interfaces, classes, and methods.
8.1. API Annotations
Every published artifact has a version number <major>.<minor>.<patch>
and all
publicly available interfaces, classes, and methods are annotated with @API. The
annotation’s Usage
value can be assigned one of the following five values:
Usage | Description |
---|---|
|
Must not be used by any code other than JUnit itself. Might be removed without prior notice. |
|
Should no longer be used; might disappear in the next minor release. |
|
Intended for new, experimental features where we are looking for feedback. |
|
Intended for features that will not be changed in a backwards-
incompatible way for at least the next minor release of the current
major version. If scheduled for removal, it will be demoted to |
|
Intended for features that will not be changed in a backwards-
incompatible way in the current major version ( |
If the @API
annotation is present on a type, it is considered to be applicable for all
public members of that type as well. A member is allowed to declare a different Usage
value of lower stability.
8.2. Tooling Support
The JUnit team plans to provide native tooling support for all JUnit users, extenders,
and tool builders. The tooling support will provide a means to check if the JUnit APIs
are being used in accordance with @API
annotation declarations.
9. Contributors
Browse the current list of contributors directly on GitHub.
10. Release Notes
10.1. 5.0.0-ALPHA
Date of Release: February 1, 2016
Scope: Alpha release of JUnit 5
10.2. 5.0.0-M1
Date of Release: July 7, 2016
Scope: First milestone release of JUnit 5
10.2.1. Summary of Changes
The following is a list of global changes. For details regarding changes specific to the Platform, Jupiter, and Vintage, consult the dedicated subsections.
-
JAR manifests in published artifacts now contain additional metadata such as
Created-By
,Built-By
,Build-Date
,Build-Time
,Build-Revision
,Implementation-Title
,Implementation-Version
,Implementation-Vendor
, etc. -
Published artifacts now contain
LICENSE.md
inMETA-INF
. -
JUnit now participates in the Up For Grabs movement for open source contributions.
-
See the up-for-grabs label on GitHub.
-
-
Group IDs, artifact IDs, and versions have changed for all published artifacts.
-
See Artifact Migration and Dependency Metadata.
-
-
All base packages have been renamed.
-
See Package Migration.
-
Old Group ID | Old Artifact ID | New Group ID | New Artifact ID | New Base Version |
---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Old Base Package | New Base Package |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
JUnit Platform
-
The
ConsoleRunner
has been renamed toConsoleLauncher
. -
ConsoleLauncher
now always returns the status code on exit, and the enable exit code flags have been removed. -
The
junit-platform-console
artifact no longer defines transitive dependencies onjunit-platform-runner
,junit-jupiter-engine
, orjunit-vintage-engine
. -
The
JUnit5
Runner has been renamed toJUnitPlatform
.-
@Packages
has been renamed to@SelectPackages
. -
@Classes
has been renamed to@SelectClasses
. -
@UniqueIds
has been removed. -
@UseTechnicalNames
has been introduced.
-
-
The Gradle plugin for the JUnit Platform has been completely overhauled.
-
The JUnit Platform Gradle plugin now requires Gradle 2.5 or higher.
-
The
junit5Test
Gradle task has been renamed tojunitPlatformTest
. -
The
junit5
Gradle plugin configuration has been renamed tojunitPlatform
.-
runJunit4
has been replaced byenableStandardTestTask
. -
version
has been replaced byplatformVersion
.
-
-
See Gradle for further details.
-
-
XML test report generation has been overhauled.
-
XML reports now contain newlines.
-
Attributes specific to the JUnit Platform that do not align with standard attributes in the de facto standard XML schema are now contained in
CDATA
blocks within the<system-out>
element. -
XML reports now use real method names and fully qualified class names instead of display names.
-
-
Unique ID in
TestIdentifier
is now aString
. -
TestSource
is now an interface with a dedicated hierarchy consisting ofCompositeTestSource
,JavaSource
,JavaPackageSource
,JavaClassSource
,JavaMethodSource
,UriSource
,FileSystemSource
,DirectorySource
, andFileSource
. -
All
DiscoverySelector
factory methods have been moved to a newDiscoverySelectors
class that serves as a centralized collection of all select methods. -
Filter.filter()
has been renamed toFilter.apply()
. -
TestTag.of()
has been renamed toTestTag.create()
. -
TestDiscoveryRequest
has been renamed toLauncherDiscoveryRequest
. -
TestDiscoveryRequestBuilder
has been renamed toLauncherDiscoveryRequestBuilder
. -
LauncherDiscoveryRequest
is now immutable. -
TestDescriptor.allDescendants()
has been renamed toTestDescriptor.getAllDescendants()
. -
TestEngine#discover(EngineDiscoveryRequest)
has been replaced byTestEngine#discover(EngineDiscoveryRequest, UniqueId)
. -
Introduced
ConfigurationParameters
which theLauncher
supplies to engines via theEngineDiscoveryRequest
andExecutionRequest
-
The
Container
andLeaf
abstractions have been removed from theHierarchicalTestEngine
. -
The
getName()
method has been removed fromTestIdentifier
andTestDescriptor
in favor of retrieving an implementation specific name via theTestSource
. -
Test engines are now permitted to be completely dynamic in nature. In other words, a
TestEngine
is no longer required to createTestDescriptor
entries during the discovery phase; aTestEngine
may now optionally register containers and tests dynamically during the execution phase. -
Include and exclude support for engines and tags has been completely revised.
-
Engines and tags can no longer be required but rather included.
-
ConsoleLauncher
now supports the following options:t
/include-tag
,T
/exclude-tag
,e/include-engine
,E/exclude-engine
. -
The Gradle plugin now supports
engines
andtags
configuration blocks with nestedinclude
andexclude
entries. -
EngineFilter
now supportsincludeEngines()
andexcludeEngines()
factory methods. -
The
JUnitPlatform
runner now supports@IncludeTags
,@ExcludeTags
,@IncludeEngines
, and@ExcludeEngines
.
-
JUnit Jupiter
-
The
junit5
engine ID has been renamed tojunit-jupiter
. -
JUnit5TestEngine
has been renamed toJupiterTestEngine
. -
Assertions
now provides the following support:-
assertEquals()
for primitive types -
assertEquals()
for doubles and floats with deltas -
assertArrayEquals()
-
Expected and actual values are now supplied to the
AssertionFailedError
.
-
-
Dynamic Tests: tests can now be registered dynamically at runtime via lambda expressions.
-
TestInfo
now provides access to tags viagetTags()
. -
@AfterEach
methods and after callbacks are now invoked if an exception is thrown by a@Test
method, a@BeforeEach
method, or a before callback. -
@AfterAll
methods and after all callbacks are now guaranteed to be invoked. -
Repeatable annotations such as
@ExtendWith
and@Tag
are now discovered in superclasses within a test class hierarchy as well as on interfaces. -
Extensions are now registered top-down within a test class or interface hierarchy.
-
Test and container execution conditions can now be deactivated.
-
InstancePostProcessor
has been renamed toTestInstancePostProcessor
.-
TestInstancePostProcessor
implementations are now properly applied within@Nested
test class hierarchies.
-
-
MethodParameterResolver
has been renamed toParameterResolver
.-
The
ParameterResolver
API is now based onjava.lang.reflect.Executable
and can therefore be used to resolve parameters for methods and constructors. -
New
ParameterContext
which is passed to thesupports()
andresolve()
methods ofParameterResolver
extensions. -
Resolution of primitive types is now supported for
ParameterResolver
extensions.
-
-
The
ExtensionPointRegistry
andExtensionRegistrar
have been removed in favor of declarative registration via@ExtendWith
. -
BeforeAllExtensionPoint
has been renamed toBeforeAllCallback
. -
AfterAllExtensionPoint
has been renamed toAfterAllCallback
. -
BeforeEachExtensionPoint
has been renamed toBeforeEachCallback
. -
BeforeAllExtensionPoint
has been renamed toBeforeAllCallback
. -
New
BeforeTestExecutionCallback
andAfterTestExecutionCallback
extension APIs. -
ExceptionHandlerExtensionPoint
has been renamed toTestExecutionExceptionHandler
. -
Test exceptions are now supplied to extensions via the
TestExtensionContext
. -
ExtensionContext.Store
now supports type-safe variants of many of its methods. -
ExtensionContext.getElement()
now returns anOptional
. -
Namespace.of()
has been renamed toNamespace.create()
. -
TestInfo
andExtensionContext
have newgetTestClass()
andgetTestMethod()
methods. -
The
getName()
method has been removed fromTestInfo
andExtensionContext
in favor of retrieving a context specific name via the current test class or test method.
JUnit Vintage
-
The
junit4
engine ID has been renamed tojunit-vintage
. -
JUnit4TestEngine
has been renamed toVintageTestEngine
.