JUnit 5

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

The project is currently in Phase 7, working on the first GA release of JUnit 5.

JUnit 5.0.0-RC3 was released on August 23, 2017.

Roadmap

Consult the wiki for details on the current JUnit 5 roadmap.

Documentation

User Guide

The JUnit 5 User Guide is available online.

API

The JUnit 5 Javadoc is available online.

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 the ALPHA, 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 us on Gitter.

Continuous Integration Builds

CI Server	OS	Description
Jenkins	Linux	Official CI build server for JUnit 5
Travis CI	Linux	Used to perform quick checks on submitted pull requests and for build matrices including JDK 8 and JDK 9 early access builds
AppVeyor	Windows	Used to ensure that JUnit 5 can be built on Windows

Code Coverage

Code coverage using Clover for the latest build is available on the Jenkins CI server. We are thankful to Atlassian for providing the Clover license free of charge.

A code coverage report can also be generated locally by executing gradlew -PenableClover clean cloverHtmlReport if you have a local Clover license file on your computer. The results will be available in junit-tests/build/reports/clover/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. Note, however, that the number of listed tests only reflects the Spock tests within the JUnit 5 test suite. To see a full representation of the number of tests executed per project, click on "See console output" on the build scan page.

Building from Source

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

gradlew clean assemble

All modules can be tested with Gradle 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 in a local Maven repository for consumption in other projects via the following command.

gradlew clean install

Dependency Metadata

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

JUnit Platform

Group ID: org.junit.platform
Version: 1.0.0-RC3 or 1.0.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-gradle-plugin (org.junit.platform.gradle.plugin)
- junit-platform-launcher (org.junit.platform.launcher)
- junit-platform-runner (org.junit.platform.runner)
- junit-platform-suite-api (org.junit.platform.suite.api)
- junit-platform-surefire-provider (org.junit.platform.surefire.provider)

JUnit Jupiter

Group ID: org.junit.jupiter
Version: 5.0.0-RC3 or 5.0.0-SNAPSHOT
Artifact IDs and Automatic-Module-Name:
- 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: 4.12.0-RC3 or 4.12.0-SNAPSHOT
Artifact ID and Automatic-Module-Name:
- junit-vintage-engine (org.junit.vintage.engine)

Java 9 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 Java 9 module path. The 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 foo.bar {
  requires org.junit.jupiter.api;
  requires org.junit.platform.commons;
  requires org.opentest4j;
}

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

Saeedaqlan6/junit5