Unstable Terrain

Software development in the real world

Posts Tagged ‘junit

Separating Unit tests from Acceptance tests in maven

leave a comment »

Have been playing with Maven a lot in the last week and a half. One thing I liked about Ant was the control over whether various classes of test would run in which target.

Found a post by Abhi which demonstrates that a judicious use of profiles will accomplish this.


Written by Trent

August 25, 2011 at 3:33 pm

Testing JUnit 4 Exception Messages

leave a comment »

In previous years, I have tested exceptions in JUnit tests using variations on the

try {
} catch (Exception expected) {
  assertEquals("Invalid Number of Foos", expected.getMessage());

pattern. Various upgrades such as codifying it into an AssertThrows class and checking the correct exception type have helped but it was a pretty ordinary solution.

Changing to JUnit 4 allowed for the annotation below:


… but testing the exception message remained ugly.

JUnit 4.7 has a neat upgrade: testing that thrown exceptions have particular messages.

For example:

public class BuilderTest {
  public ExpectedException thrown = ExpectedException.none();

  public void invalidMessagesShouldThrowAutoPopulateException() {
    thrown.expectMessage("too many autopopulate errors");


It also accepts a Hamcrest-style matcher if you want to do something more complicated.

Written by Trent

February 18, 2011 at 4:19 pm

Posted in Software Development, Tools

Tagged with , ,

Ant Junit task Addendum: forkmode

leave a comment »

I mentioned previously about using the ant junit task with fork=false.

However, some tools such as EMMA insert shutdown hooks, so require forking. In addition, classloader issues may require you to fork to save your own sanity.

Turns out there’s a more robust solution.

<junit  haltonfailure="yes"
    <classpath refid="test.class.path.with.test.classes" />
    <formatter type="xml" />
    <batchtest toDir="${test.reports}">
        <fileset dir="${test.classes.dir}">
            <include name="**/*Test*.class" />

A new JVM will be forked, but all tests will be run inside that single forked JVM, increasing the speed of your tests substantially. If you have some tests that have side-effects, you can put them into a separate batch and change the forkmode to ‘perBatch‘, effectively isolating them while retaining the speed of the rest of your tests.

So, try it and see how much faster your build goes.

Written by Trent

July 26, 2010 at 6:44 pm