slukes / junit5

The next generation of JUnit.

JUnit 5

This repository is the home of the next generation of JUnit, JUnit 5.

Latest Releases

• General Availability (GA): JUnit 5.3.2 (November 25, 2018).
• Preview (Milestone/Release Candidate): JUnit 5.4.0-M1 (December 23, 2018).

Documentation

• User Guide
• Javadoc
• Release Notes
• Samples

Contributing

Contributions to JUnit 5 are both welcomed and appreciated. For specific guidelines regarding contributions, please see CONTRIBUTING.md in the root directory of the project. Those willing to use milestone or SNAPSHOT releases are encouraged to file feature requests and bug reports using the project's issue tracker. Issues marked with an up-for-grabs label are specifically targeted for community contributions.

Getting Help

Ask JUnit 5 related questions on StackOverflow or chat with the team and the community on Gitter.

Continuous Integration Builds

CI Server	OS	Status	Description
Travis CI	Linux, macOS		Official CI build server for JUnit 5. Used to perform quick checks on submitted pull requests and for build matrices including the latest released OpenJDK and early access builds of the next OpenJDK
AppVeyor	Windows		Used to ensure that JUnit 5 can be built on Windows

Code Coverage

Code coverage using JaCoCo for the latest build is available on Codecov.

A code coverage report can also be generated locally via the Gradle Wrapper by executing gradlew -PenableJaCoCo clean jacocoRootReport. The results will be available in build/reports/jacoco/jacocoRootReport/html/index.html.

Gradle Build Scans

JUnit 5 utilizes Gradle's support for Build Scans. An example build scan for JUnit 5 can be viewed here.

Building from Source

You need JDK 11 to build JUnit 5.

All modules can be built with the Gradle Wrapper using the following command.

gradlew clean assemble

All modules can be tested with the Gradle Wrapper using the following command.

gradlew clean test

Since Gradle has excellent incremental build support, you can usually omit executing the clean task.

Installing in Local Maven Repository

All modules can be installed with the Gradle Wrapper in a local Maven repository for consumption in other projects via the following command.

gradlew clean publishToMavenLocal

Dependency Metadata

The following sections list the dependency metadata for the JUnit Platform, JUnit Jupiter, and JUnit Vintage.

See also https://repo1.maven.org/maven2/org/junit/ for releases and https://oss.sonatype.org/content/repositories/snapshots/org/junit/ for snapshots.

JUnit Platform

• Group ID: org.junit.platform
• Version: 1.3.2 or 1.4.0-M1 or 1.4.0-SNAPSHOT
• Artifact IDs and Automatic-Module-Name:
  • junit-platform-commons (org.junit.platform.commons)
  • junit-platform-console (org.junit.platform.console)
  • junit-platform-console-standalone (N/A)
  • junit-platform-engine (org.junit.platform.engine)
  • junit-platform-launcher (org.junit.platform.launcher)
  • junit-platform-reporting (org.junit.platform.reporting)
  • junit-platform-runner (org.junit.platform.runner)
  • junit-platform-suite-api (org.junit.platform.suite.api)
  • junit-platform-testkit (org.junit.platform.testkit)

JUnit Jupiter

• Group ID: org.junit.jupiter
• Version: 5.3.2 or 5.4.0-M1 or 5.4.0-SNAPSHOT
• Artifact IDs and Automatic-Module-Name:
  • junit-jupiter (org.junit.jupiter)
  • junit-jupiter-api (org.junit.jupiter.api)
  • junit-jupiter-engine (org.junit.jupiter.engine)
  • junit-jupiter-migrationsupport (org.junit.jupiter.migrationsupport)
  • junit-jupiter-params (org.junit.jupiter.params)

JUnit Vintage

• Group ID: org.junit.vintage
• Version: 5.3.2 or 5.4.0-M1 or 5.4.0-SNAPSHOT
• Artifact ID and Automatic-Module-Name:
  • junit-vintage-engine (org.junit.vintage.engine)

Bill of Materials (BOM)

• Group ID: org.junit
• Artifact ID junit-bom
• Version: 5.3.2 or 5.4.0-M1 or 5.4.0-SNAPSHOT

Java Module Names

All published JAR artifacts contain an Automatic-Module-Name manifest attribute whose value is used as the name of the automatic module defined by that JAR file when it is placed on the module path. The automatic module names are listed above in the Dependency Metadata section.

This allows test module authors to require well-known JUnit module names as can be seen in the following example.

open module test.mylib {
  requires mylib;
  requires org.junit.jupiter.api;
}

The junit-platform-console-standalone JAR does not provide an automatic module name as it is not intended to be used as a module.