In a well-organized build process, you want lightning-fast unit tests to run first, and provide whatever feedback they can very quickly. A nice way to do this is to be able to class your tests into different categories. For example, this can make it easier to distinguish between faster running unit tests, and slower tests such as integration, performance, load or acceptance tests. This feature exists in TestNG, but, until recently, not in JUnit.

Indeed, this has been missing from the JUnit world for a long time. Using JUnit, I typically use test names (integration tests end in 'IntegrationTest', for example) or packages to identify different types of test. It is easy to configure a build script using Maven or Ant to run different types of test at different points in the build lifecycle. However it would be nice to be able to do this in a more elegant manner.

A recent question on Twitter about my JUnit Kung Fu talk got me thinking - is it possible to combine the expressivity of Hamcrest asserts with the power of parameterized testing? The answer is, of course, yes. Hamcrest expressions are not limited to assertThat statements - they can be used in isolation as well.

Any Test-Driven Development practitioner will tell you, Test-Driven Development is a design strategy, not a unit-testing technique. Writing unit tests are a means, not an end. The goal is to write better quality, more reliable, and more accurate code.

JUnit 4.7 introduced a few features that make it a little easier to work with exceptions. JUnit 4 introduced the expected parameter, which makes a test succeed if and only if a certain exception is thrown. For example, in the following code sample, we are testing a UserManager class. When the login() function is called, it should throw an UnknownUserException when no user is found.

Let's not be pedantic. Write unit tests before you code a method, or after it - in my experience, it matters little, as long as you think about and write the tests at roughly the same time as you write the code. It's coming back to do the tests later (or not coming back at all) which causes problems. Personally, I like to write unit tests just before or immediately after writing small chunks of code - it doesn't break the flow, because it is part of the flow.