Sponsors & Crowdfunding • Three companies had pledged to sponsor a developer each for 6 weeks (prior to crowdfunding). • Additional developers were funded through a crowdfunding campaign on Indiegogo.
Runner • Very powerful: Almost every aspect of test execution can be changed • But: You can only have one Runner per test class! • You can’t combine Runners, e.g. SpringJUnit4ClassRunner + Parameterized
Rules • Extension mechanism introduced in JUnit 4.7 • Wraps execution of a test (@Rule) or a test class (@ClassRule) • Designed to be combined — great for simple use cases • But: a single rule cannot be used for method-level and class-level callbacks, no support for instance-level callbacks
–Johannes Link, https://jaxenter.com/crowdfunding-for-junit-lambda-is- underway-119546.html „The success of JUnit as a platform prevents the development of JUnit as a tool.“
Vision • Decouple test execution and reporting from test definition to ease future development • Rethink JUnit’s extensibility story • Making use of Java 8 features (e.g. Lambdas, Streams, Interface default methods) for better assertions, generating test cases, etc.
Challenges • Changing the way JUnit tests are being run from outside requires support from IDE vendors and build tool providers. • Compatibility with older releases has to be preserved: Old tests still need to work
Design Goals • Modern programming model for writing tests (Java 8!) • Powerful extension model with a focus on composability • API Segregation: Decouple test execution/reporting from test definition • Compatibility with older releases + migration path • Modularization + no external dependencies
–Liam Clark, Jean de Leeuw, Benjamin Los, Thomas Overklift „In this industry, where the common opinion is that complete rewrites generally result in failure, what made the JUnit 5 team decide to go for a complete rewrite?“
How we cheated the Big Redesign Fallacy • We didn’t have to rely on JUnit 4 for the requirements • Very little ongoing, parallel development on JUnit 4 • No race between old and new
Separation of Concerns 1. An API to write tests (Jupiter API) 2. Extensible mechanisms to discover and execute tests (Test Engine SPI) 3. An API for test execution by tools (Launcher API)
JUnitPlatform Runner for a single class import org.junit.jupiter.api.Test; @RunWith(JUnitPlatform.class) public class JupiterTest { @Test void someTest() { // test something } }
JUnitPlatform Runner in suite mode @RunWith(JUnitPlatform.class) @SelectPackages("com.acme") @IncludeEngines({"junit-jupiter", "junit-vintage"}) public class JUnit4SuiteDemo { // this class can be run using JUnit 4 }
Test Execution • IDEs: • IntelliJ supports JUnit 5 ≥ M2 since 2016.2 • Eclipse support is available on a branch (see Instructions). Official release slated for Oxygen.1. • Interim solution for other IDEs: JUnitPlatform Runner • Gradle/Maven: Plugin/Provider available • see https://github.com/junit-team/junit5-samples • Manually: ConsoleLauncher
Compatibility • Backward compatibility (junit-vintage-engine) enables gradual migration of tests to Jupiter API • Forward compatibility (JUnitPlatform Runner) allows test execution with “old” tools
–Kevin Cooney, https://github.com/junit-team/junit5/wiki/Core- Principles „Prefer extension points over features: It's better to enable new functionality by creating or augmenting an extension point rather than adding the functionality as a core feature.“
Extension Points over Features • Once we create an API, we often cannot easily modify it. • Third-party libraries can make mistakes and fix them because they have fewer users. • An extension point can potentially be used for different features, or for implementing the same feature in a more flexible way.
Good at one thing • Simpler extension points allow for easier composition. • Don't be afraid to introduce new extension points to handle weak points in existing ones.
Registration via @ExtendWith • Annotate your test classes or methods to register extensions • Supports an arbitrary number of extensions at the same time • May be used as a meta-annotation
Spotless • Used to enforce source code formatting in the Gradle build • No more reviewing of formatting changes like in JUnit 4 pull requests • very annoying at times, but also very helpful in keeping consistency
–Liam Clark, Jean de Leeuw, Benjamin Los, Thomas Overklift „The JUnit 5 team currently eliminates cyclic dependencies through the DeGraph Gradle plugin. Cyclic dependencies are not ideal, but Java compiles them correctly, so why is the JUnit 5 team so insistent on removing them?“
Degraph • Check each module for package cycles • JUnit 4 package structure has deteriorated over time • Keep dependencies between packages clear in the presence of pull requests etc. • Keep door open for moving a package into a separate module etc.
–Liam Clark, Jean de Leeuw, Benjamin Los, Thomas Overklift „What is the reason why JUnit 5 is against wild card imports? Is this because of performance and potential name collisions, or are there perhaps different reasons?“
CI • Fast feedback on pull requests: • Travis (Linux), multiple JDKs • AppVeyor (Windows) • Jenkins hosted on CloudBees for publishing snapshot artifacts and documentation
Asciidoctor • User Guide (snapshot version) is published with every build to GitHub Pages • Example source code is compiled, tests are executed, and then included into User Guide
Definition of Done • Particularly important in a distributed team • Part of the pull request template • Includes items that cannot be checked by the build
Roadmap to GA • 5.0.0-M4 (April 2017): Parameterized/RepeatedTests ✔ • 5.0.0-M5 (May 2017): Java 9 compatibility • 5.0.0-RC1 (June 2017): Last fixes before GA • 5.0.0 (July 2017): GA
Getting Started User Guide: http://junit.org/junit5/docs/current/user-guide/ Sample projects for Gradle and Maven: https://github.com/junit-team/junit5-samples Javadoc: http://junit.org/junit5/docs/current/api/