Hamcrest is a neat little library that lets you write more fluent and readable tests. For example, rather than writing:

    assertEquals("red", color);

    assertThat(color,is("red"));

A version of Hamcrest is actually bundled with JUnit. However it is somewhat dated, and the more recent versions of Hamcrest come with a lot more features, particularly with regards to working with collections. You can use the latest version of Hamcrest by using the junit-dep dependency instead of junit, and configuring your dependencies as shown here:

    <dependency>
	    <groupId>junit</groupId>
	    <artifactId>junit-dep</artifactId>
	    <version>4.10</version>
	    <scope>test</scope>
	    <exclusions>
	        <exclusion>
	            <groupId>org.hamcrest</groupId>
	            <artifactId>hamcrest-core</artifactId>
	        </exclusion>
	    </exclusions>
	</dependency>
	<dependency>
	    <groupId>org.hamcrest</groupId>
	    <artifactId>hamcrest-library</artifactId>
	    <version>1.3.RC2</version>
	</dependency>

I am a big fan of using code coverage as a developer tool to promote more reliable, better tested code. The merits and limits of code coverage are widely discussed and fairly well known. Essentially, the big strength of code coverage is revealing code that has not been exercised by your unit tests. It is up to you, as a software development professional, to establish why this code has not been exercised by your unit tests, and whether it is significant. It is also up to you to ensure that your tests are of sufficient quality to ensure that the code that is exercised during the tests is effectively well tested.

In this article I don't want to discuss those aspects of code coverage. Instead I want to look at how code coverage can be a useful tool in a TDD practitioner's toolbox, in particular during the refactoring phase. Indeed, Using code coverage to help with refactoring, when combined with TDD, is a powerful tool.

Sometimes, even if you are generally applying good Test Driven Development practices, you can find yourself slipping into what I call Integration-Test Driven Development, or ITDD. Essentially, this is when you use a high level integration or functional test to know if your low-level code changes are having the desired effect. So you need to build several modules of your app, or even your whole app, to see if your code is correct.

This is a Bad Thing.

There have been some articles and tweets about code coverage recently, and it seems that many developers are still laboring under a few misconceptions in this area.

Code coverage can be a very useful metric. However you need to know how, and when, to use it. The link between code coverage and test quality is tenuous at best - in short, high code coverage is, in itself, no guarantee of well tested code. And increasing code coverage for the sake of code coverage will not necessarily improve either the quality of your tests or the quality of your application. It is easy (and obviously a largely futile exercise) to achieve high code coverage metrics without actually testing anything at all.