Why JUnit needs your support
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.
Obstacles for evolving JUnit
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.
The Vision
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 hierachies, 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.
What we will do with the money
We aim for a minimum goal of 25,000 EUR. While researching crowdfunding basics we had to learn and accept
that about a quarter of the raised money will go directly into taxes and
into fees for the crowdfunding platform and payment providers. This will leave us with approximately 19,000 EUR.
This sum will be used to
- Fund an onsite kick-off workshop with all participating developers and a few key stakeholders like IDE and build tool developers. Estimated costs are 4,000 EUR including travel (a few oversea flights) and accomodation.
- Provide for 6 weeks of intensive, full-time, collaborated work on JUnit by at least four developers. Three developers are funded by their employers for 6 weeks, so we only need to cover travel expenses for those.
In case we raise more than the minimum:
- If we raise an additional 10,000 EUR at least one additional full-time developer will come on board.
- In case we raise even more, the remaining money will serve to fund additional periods of stabilizing and evolving the new JUnit.
- Any money not being used by the end of 2016 will be donated to a charity or a software-related foundation.
We will account for all money taken from the funding sum in a publicly viewable location, e.g. on the campaign’s website.
The Team
The team consists of 3 current JUnit core committers: Marc Philipp (full-time campaign developer), David Saff (consulting developer), Kevin Cooney (consulting developer). The other full-time developers are Stefan Bechtold, Sam Brannen, Johannes Link and Matthias Merdes. All of them have extensive experience with Java, JUnit and other testing libraries.
Challenges
Changing the way JUnit tests are being run from outside requires support from IDE vendors and build tool providers. That’s why we have been in close contact during the previous months and are planning to get their feedback in the kick-off workshop.
Other ways to support the campaign
Apart from donating to the campaign you can support the project by
- Telling others about it on Twitter, Facebook and other social networks
- Following the code as it evolves on GitHub, trying it out and giving us feedback.
