The JUnit project released the 4.4 version of the popular Java unit testing framework. In the project's release notes, project leaders David Saff and Kent Beck note that:

JUnit is designed to efficiently capture developers' intentions about their code, and quickly check their code matches those intentions. Over the last year, we've been talking about what things developers would like to say about their code that have been difficult in the past, and how we can make them easier.

Among the features introduced in this version is a new assertion syntax originally developed by Joe Walnes. The new syntax has the form:

 assertThat([value], [matcher statement]);

This makes statements such as the following possible:

    assertThat(x, is(3));
    assertThat(x, is(not(4)));
    assertThat(responseString, either(containsString("color")).or(containsString("colour")));
    assertThat(myList, hasItem("3"));

The advantages of this feature, according to the JUnit 4.4 release notes are a more readable syntax, better error messages, and the ability to combine matchers for a particular condition.

The new assertion syntax also enables two additional JUnit 4.4 features: assumptions and theories. Of the former, Saff and Beck write that:

Ideally, the developer writing a test has control of all of the forces that might cause a test to fail. If this isn't immediately possible, making dependencies explicit can often improve a design. For example, if a test fails when run in a different locale than the developer intended, it can be fixed by explicitly passing a locale to the domain code.

However, sometimes this is not desirable or possible. It's good to be able to run a test against the code as it is currently written, implicit assumptions and all, or to write a test that exposes a known bug. For these situations, JUnit now includes the ability to express "assumptions:"

import static org.junit.Assume.*

    @Test public void filenameIncludesUsername() {
       assumeThat(File.separatorChar, is('/'));
       assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
    }

    @Test public void correctBehaviorWhenFilenameIsNull() {
       assumeTrue(bugFixed("13356"));  // bugFixed is not included in JUnit
       assertThat(parse(null), is(new NullDocument()));
    }

Beck and Saff also note that in the JUnit 4.4 release, a failed assumption will still let a test pass, but in future versions this behavior may change.

Noting that,

A test captures the intended behavior in one particular scenario. A theory captures some aspect of the intended behavior in possibly infinite numbers of potential scenarios.

JUnit 4.4 introduces "theories," a feature borrowed from the Popper project.

  @RunWith(Theories.class)
    public class UserTest {
      @DataPoint public static String GOOD_USERNAME = "optimus";
      @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";

      @Theory public void filenameIncludesUsername(String username) {
        assumeThat(username, not(containsString("/")));
        assertThat(new User(username).configFileName(), containsString(username));
      }
    }

Defining general statements in this way can jog the developer's memory about other potential data points and tests, also allows automated tools to search for new, unexpected data points that expose bugs.

What do you think of the new JUnit 4.4 features?

assertThat(responseString, anyOf(containsString("color"), containsString("colour")));
// ==> failure message:
// java.lang.AssertionError: 
// Expected: (a string containing "color" or a string containing "colour")
//      got: "Please choose a font"

    assertThat(x, is(3));
    assertThat(x, is(not(4)));
    assertThat(responseString, either(containsString("color")).or(containsString("colour")));
    assertThat(myList, hasItem("3"));

    assertThat(x).is(3);
    assertThat(x).isNot(3);
    assertThat(responseString).either.containsString("color").or.containsString("co lour");
    assertThat(myList).hasItem(3);

>     assertThat(x).is(3);
>     assertThat(x).isNot(3);
>  assertThat(responseString).either.containsString("color").
> or.containsString("colour");
>     assertThat(myList).hasItem(3);
>