[Updated 6/4/17 Revisited this, appears still broken]
One 0f the features I’d proposed for JUnit, default method tests (based on my contract tests package), made it into JUnit5 so it’s been on my queue to try it out. When I settled into try it, I took my standard approach to learning a new tool, I grabbed one of my existing projects and set about applying JUnit5 to it.
I looked over the JUnit docs and some examples and it all looked pretty good. But when I started to use it in my project I caught a whiff of a bad smell pretty quickly. The project I’d chosen was built with gradle. Gradle is by far my build tool of choice at this point. JUnit4 is well integrated into gradle and you don’t need to do much more then add a single dependency to use it. JUnit5 had a new plugin for gradle, which required a bit more hand holding, and there were several additional dependencies, some required and some optional.
Migrating my tests was fairly painless. Some of the annotation name changes seemed a tad gratuitous but no biggy. Configuring the new plugin to actually work with the tests was certainly not as easy as it was for JUnit4 but t got done in in minutes not hours.
And then the plugin’s smell turned into a reek when I pushed the code and it fell over in continuous integration. The JUnit part was fine, all my tests passed without problem, but my code coverage report wouldn’t run. Not at all. No Jacoco output.
I am a TDD practitioner, so mostly my tests come first. That said I’m also a code coverage fan. I like to know how well I’m doing with the tests I write, and a nag when I cheat and just crank out boilerplate code untested. I depend on Jacoco for that. Sure enough a quick search proved my fears true. The JUnit5 gradle plugin just does not work with Jacoco. Gradle being what it is, i.e. very open to hacking, I found several “fixes” but they didn’t work for me.
So the JUnit5 work is now off on a code branch, and I’m back to JUnit4. I’ll keep an eye on things and when it’s sorted out I’ll revisit it.