Campaign page on Indiegogo Campaign Contributors Follow @junitteam on Twitter
Each of these companies will fund a developer for 6 weeks. They will not receive any money collected through the campaign.
Thank you to all other people, companies, and organizations that have contributed already! Please check out our contributors page.
With 43 million downloads from Maven Central in 2014 JUnit still is the default testing library for Java. Millions of projects rely on it being both stable and allowing to test the latest features of the latest JDK. Moreover, many other testing libraries hook into JUnit as a way to enable IDE and build tool integration. Keeping JUnit in shape is a major task for those maintaining and evolving the library.
As of today, none of the active JUnit maintainers are payed by their employer to do this work. Not surprisingly many unresolved issues have piled up and, what’s worse, there is no hope to get JUnit to support and make use of all the features in Java 8 any time soon. Since Lambdas are the most prominent of those features, we borrowed their name for the campaign.
This campaign will allow a team of long-time JUnit committers, backed by a few experienced Java developers, to focus on getting JUnit ready for the years—and JDKs—to come.
A major design goal of JUnit has always been simplicity. JUnit 4 was released 10 years ago and has served its purpose very well. Since then many things have changed: Java got a couple of new versions and many new testing frameworks and ideas about testing have popped up.
The basic design of JUnit, however, has remained the same since 2005. Some constructs like Rules were added, but at the same time backwards compatibility has always been and will continue to be the major goal of evolving JUnit. A number of issues have increasingly slowed down its evolution:
Runners have found a widespread use and become a crucial concept to extend JUnit. Writing a custom runner is a very powerful way to customize how a test class is instantiated, how its children are collected, how they are run, reported, and so on. However, you can only have a single runner for each test class. For example, combining SpringJUnit4ClassRunner and Parameterized is not possible at the moment. We want to separate the different concerns, for which the runner is currently responsible, into separated interfaces.
The current execution model requires all test cases to be known a-priori. This prevents the dynamic creation of test cases as response to observed behaviour during test execution. This also means that you cannot use Streams (Java 8), e.g. in combination with @Parameters, to create your test data.
All IDEs and build tools include support for JUnit. While that makes it really easy to execute JUnit tests, on the flip side the IDEs and build tools are tightly coupled to JUnit internals. Some IDEs and build tools use internal JUnit classes or even reflection to circumvent the absence of a JUnit API that does what they want. For example, there is no extensible way to link to a test location in case it is not a Java method. Those “tricks” complicate the evolution of JUnit tremendously, and even render some changes virtually impossible. Therefore, we want to closely work with IDE and build tool developers to add features their users need in an extensible way.
We’ve identified two main areas to focus on during the upcoming JUnit overhaul:
Decouple test execution and reporting from test definition and provisioning: This will greatly simplify further evolution of JUnit and allow users to mix test specifications from different test libraries—like JUnit, Spock, ScalaTest and so on—more easily. Other testing libraries should only depend on the test execution/reporting API of JUnit, not on the test definition API (e.g. Runner).
Rethinking the JUnit’s extensibility story: Runners, Rules, subclassing and other techniques will be revamped into a cohesive set of constructs to enhance JUnit and to allow—if possible—the seamless combination of individual extensions.
Making use of Java 8 features (Lambdas, Streams, Interface default methods) for better assertions, generating test cases, formulating test hierarchies, testing asynchronous code and other stuff: We will provide those extensions in additional libraries to keep the JUnit core compatible with older JDKs.
All development will happen openly on GitHub in order to foster early feedback and detect problems as soon as possible.
