For me JUnit is the most important library of the Java universe. But I think a new version of it is overdue. With it’s approach of having a method definition as a test definition JUnit is mighty inflexible and needs various hacks … sorry features, to do what you really should be able to do with basic (Java 8) language features.
If you aren’t sure, what I’m talking about, check out this article about ScalaTest. Something like this should be the standard for JUnit.
Of course you can implement your own TestRunner to get something like this going. But there are already many important TestRunners (SpringJUnit4ClassRunner anyone?) and they have the huge drawback that you can have only one of them.
Another alternative would be to just say good-bye to JUnit and use a different Testframework. But all these other Testframeworks don’t have the support from third-party tools that JUnit has, so I’d really prefer JUnit to evolve, instead of it being replaced by something else.
I was thinking about these issues for quite some time and actually brought them up on the JUnit mailing list, with lots of interesting feedback, but nothing happened. So when I met Marc, one of the JUnit committers at the XP-Days we started to discuss the situation, joined by Stefan, another JUnit committer and various XP-Days participants.
And as so often nothing is as easy as it seems. JUnit is a very successful library, but it also doesn’t offer all the features people want or need. This has the effect that people use JUnit in all kinds of weird ways, which makes it really hard to evolve. E.g. Marc and Stefan told a story about the latest version of JUnit where they learned that a certain IDE uses reflection on private fields of JUnit, resulting in a “Bug” when the name of that field was changed.
Therefore it seems, before one can make a change as big as a different default TestRunner, one has to revamp JUnit.
I envision something like the following:
- gather the various features that others bolted onto JUnit, that probably should be part of JUnit itself.
- provide a clean, supported API for those
- apply gentle pressure and time for third parties to switch to the new APIs
- behind that API provide a new more flexible way to create tests
- profit
And since JUnit is an open source project and all developers seem to work only in their private time on it, we started right there at the XP-Days gathering stuff that needs consideration. I put the results in a wiki page in the JUnit github repository. Get over there and see if you can add something.
| Reference: | Quo Vadis JUnit from our JCG partner Jens Schauder at the Schauderhaft blog. |
I’ve ditched JUnit for Spock… it’s a lot more concise, has separation of setup/stimulus/response, and the BDD style approach discourages monolithic and rambling tests you see with JUnit/TestNG.
Custom runners such as SpringJUnit4ClassRunner are no longer necessary since the advent of JUnit Rules. Many libraries who had custom runners are now implementing the same with rules. This allows you to use as many test set-up libraries as you wish and still be able to use theories and parameterized tests.