Unit tests have most value when they’re easy to read and understand. Unit tests typically follow a very straightforward pattern:
So long as this pattern is obvious in the test, the test is readable.
Integration tests are a valuable tool in the development of robust, quality software. Once each individual component has been unit tested, the integration test gives some confidence that the system stack as a whole does what is expected. Like unit tests, a great deal of the value of integration tests comes from the regression suite that they create. After any defect fix or enhancement to software, the unit and integration tests confirm that all existing features do exactly what they did before. If these tests are automated, they cost nothing to run and they’ll stay silent unless a defect is discovered.
I’ve looked at unit testing a few times in the past but this post explains how to integration test the full stack – database, Java application and web server. In this case, I’m running the tests as part of the Maven build lifecycle. As usual, I’m working from the Spanners demo (available for download), mainly working against the spanners-struts web component.
I’ve been looking a lot recently at JUnit (and TestNG) tests on a code base I’m not too familiar with. In many cases I was not convinced that the tests were adequate but it took a fair bit of investigation before I could be satisfied that this was the case. I would need to look at the tests, then look at the code it’s meant to exercise, then try to work out in my head if the test covers everything it should. To make this process a bit easier, I’ve started running code coverage analysis using Emma. While this doesn’t tell me if the test is good or not, it does show me at a glance how much code is covered by the test and exactly which lines, methods and classes are missed. This is usually a good first approximation for the quality of the test case.
I’ve found Emma to be a useful tool to run after I think I’ve written my test cases and got them working. Running the test case tells me if the code being tested works. Running Emma tells me if I’ve tested enough of the code. There’s no point in having 100% test case successes if the tests themselves only exercise 50% of the code.