Stop dissing JUnit

JUnit seems to have come under fire recently, with articles such as this, and posts like this one from Geoff and this one from Cedric. The Artima article complains that JUnit’s reporting features are underdeveloped, and Cedrid & Geoff want to see success messages as well as failure ones.

JUnit is a ‘unit testing’ tool. Its supposed to be run many times a day. Its output is supposed to be transient. All the tests are supposed to pass all the time. Red bar / green bar. Pass or fail. If all the tests are passing it should remain silent. If a test fails, print a useful message. If you have a suite of thousands of tests, how easy is it to find 1 failure message if its mired inside 999 inane ‘test passed, foo does equal foo’ printouts?

The same goes for reporting. It is actually possible to get detailed reports from JUnit as XML, which can be processed by an ANT task to produce nice looking web pages, but if its being used correctly, all the tests would always be at 100%, as you don’t commit if any of the tests are failing, right?

Bolting on extra features blurs the line between functional testing and unit testing, and I for one am happy for JUnit to remain clearly focussed on doing one job very well, which it does admirably.

Side note: The Artima article is called ‘Why we refactored JUnit’. Following neatly on from my earlier post, what they did was neither big-R or little-R. What they actually did was write a brand new, JUnit testcase compatible tool from the ground up. Refactoring is defined as ‘improving the design of existing code’. In the strictest sense the only people who can refactor JUnit are the JUnit committers and contributers, and the result would still have been JUnit, with all the same behaviour, but with a cleaner internal structure.

5 thoughts on “Stop dissing JUnit

  1. I figured people would wonder why we redesigned JUnit, and that’s why we started out by publishing the “Why We Refactored JUnit” article. You’re right, I should have called the article “Why We Redesigned JUnit.” Many people have called me on that. I considered it a refactoring process at the time because we were taking JUnit’s design, though not the code, and cleaning it up. But using the word “refactor” has mislead some people. I’ve considered changing the title post-facto, but haven’t done so as yet.

    The trouble I had with JUnit, as I describe in the Why article, was that it was hard to integrate with. You may consider that “bolting on other features,” but I consider an important aspect of any public API. Many many people have extended JUnit, just look at In short, I got so frustrated trying to figure out how to integrate my signature test tool with JUnit that I decided to just refactor (wrong word) it into a simple test toolkit with no gui that I only used to drive the signature test stuff. That’s why I started the project. Later, the project got away from us. It got a GUI. It blew up into a big huge task, and we ultimately decided to quit. But shortly thereafter we decided to finish.

    The reasons I decided to finish were different from the reason I decided to start. One was, as Matt Henricson pointed out, that I wanted to have some useful open source software available through to generate some interest in the website. Another reason was that I wanted (and still plan) to write a short series of articles that compare JUnit’s and SuiteRunner’s design, and talk about what I think is important in design. So it is a visual aid, of sorts. Lastly, SuiteRunner is a source of many articles that I have written and continue to write about testing. Those were the three main reasons I decided to finish the project.

    That’s Why We Redesigned JUnit. Why should you use SuiteRunner? If you have an existing infrastructure in JUnit tests, then you can consider using SuiteRunner as your JUnit runner. It gives you a few extra nice things, and will be giving a few more nice things in the coming weeks and months as we make a few enhancements. Info about that is here:

    By the way, what’s the difference between big-R and little-r refactoring?

  2. I my defence, I was not dissing JUnit. I’m a big a fan as the next guy.

    What I was commenting on in my post was Cedric’s proposition to use a more java-like and thus more intuitive if-then-else structure with the JUnit asserts.

    If you have ever pair programmed with someone who has never written a Unit Test before, the syntax takes getting used to. I have found that it is quite natural to think of “assertTrue” as “assert-if-true” and “assertEquals” as “assertIfEquals”. Based on this experience I was agreeing with Cedric that the if-then-else method signature is more intuitive.

    That being said, there are some times when you may want all the messages – failures or successes. If you were writing a unit testing tool and you wanted to build it on top of JUnit, you would be stuck with only the failures.

    I do like JUnit. It is a fantastic tool for Java developers to write unit tests.

    A little dissing is good sometimes to stir up our otherwise boring development lives! 😉

  3. I feel I should apologise for the confrontational style of the original post. But inflammatory material always generates more interest! Discussions are good, but no ad hominem attacks were implied or intended.

    (And I got to use the phrase ‘ad hominem’ like I know what it means…)

Comments are closed.