Testing: The Dark Side?
It feels like an eternity since I last sat down to write some blog content!!
The last month or so I have been busy updating a ‘JUnit Goodness’ presentation for use at the Auckland JUG October 2009 meeting. The presentation focuses on 3 aspects of JUnit 4 that I feel may have slipped under the radar of developers introduced to JUnit at version 3. Parameterized tests, matcher assertions and the @Ignore annotation were the 3 aspects I chose to include in this presententation.
The parameterzied test section of the presentation attempts to outline a process that may lead a developer to utilize a parameterized test. The realization that duplicated code can be replaced by a looping test leads the devloper naturally in the direction of a parameterized test. The presentation aims to offer answers regarding why and when to use parameterized tests and how to write them. Also included in the presentation is a named parameterized test extension and an XML data driven parametrized test extension that I had recently implemented.
Matcher assertions arrived in JUnit 4 via JMock. The presentation aims to demonstrate the advantages of using matcher assertions compared to the legacy JUnit assertions. Matcher assertion readability, clarity of failure messages, combination matcher usage and the benefits of list matchers are all presented. The creation of custom matchers is also present, albeit through a crude over simplified example. To finish the presentation there is a look at the somewhat under utilized IMHO @Ignore annotation and how it can fit in to improved testing practices.
Auckand JUG Duke
The majority of those present at the presentation were still using JUnit even though TestNG has built up quite a following and viewed by some as the next generation test tool. TestNG has useful features such as parallel testing and data driven testing using the @DataProvider annotation that JUnit does not. Why has there not been a shift to this next generation test tool? Is it down to the lazy developer syndrome? The we know this tool, why waste time learning a similar tool attitude? Some of the attendees were aware of TestNG and the benefits it offers when writing certain types of tests – yet still used JUnit for there project test needs.
Many of those present were unaware of the benefits that the 3 aspects presented provided. There was the odd attendee who had dabbled with one or two of the aspects, but none had really dug too deep. Hopefully I provided everyone with something to think about whenever they are writing JUnit tests in the future.
I had expected the parameterized tests section, particularly the named and XML data-driven extensions would be the ‘WOW’ factor of this particular presentation. This was not the case though. The actual ‘WOW’ factor turned out to be the clarity of the matcher assertion failure messages compared to their legacy equivalents. Flicking between the two versions on the big projector screen seemed to exacerbate the clarity.
I would be surprised to see any of the developers present not using matcher assertions from now on based on what they saw. The @Ignore annotation usage did lead into a group discussion regarding how useful it was, how it could be abused and the best ways to use it.
I plan to upload a slightly updated version of the presentation to SlideShare later this week.
Purchase JUnit In Action 2nd Edition MEAP Edition
When writing JUnit tests developers often add log statements that can help provide information on test failures. During the initial attempt to find a failure a simple System.out.println() statement is usually the first resort of most developers.
