4.5 Unit Test Granularity

4.5.1 Problem

You want to know how fine-grained your unit tests should be.

4.5.2 Solution

Each unit test should check one specific piece of functionality. Do not combine multiple, unrelated tests into a single testXXX( ) method.

4.5.3 Discussion

Each test method can have as many assertXXX( ) calls as you like, but they can lead to problems:

public void testGame(  ) throws BadGameException {
    Game game = new Game(  );
    Ship fighter = game.createFighter("001");
    assertEquals("Fighter did not have the correct identifier",
        "001", fighter.getId(  ));
    Ship fighter2 = game.createFighter("001");
    assertSame("createFighter with same id should return same object",
        fighter, fighter2);
    assertFalse("A new game should not be started yet", game.isPlaying(  ));
}

This is a bad design because each assertXXX( ) method is testing an unrelated piece of functionality. If the first assertEquals( ) fails, the remainder of the test is not executed. When this happens, you won't know if the other tests are functional.

Example 4-2 shows a refactored test case that tests various aspects of our game independently. We will see how to remove the duplicated code in Recipe 4.6 when we talk about setUp( ) and tearDown( ).

Example 4-2. Refactored tests

public void testCreateFighter(  ) throws BadGameException {
    Game game = new Game(  );
    Ship fighter = game.createFighter("001");
    assertEquals("Fighter did not have the correct identifier",
        "001", fighter.getId(  ));
    game.shutdown(  );
}

public void testSameFighters(  ) throws BadGameException {
    Game game = new Game(  );
    Ship fighter = game.createFighter("001");
    Ship fighter2 = game.createFighter("001");
    assertSame("createFighter with same id should return same object",
        fighter, fighter2);
    game.shutdown(  );
}

public void testGameInitialState(  ) throws BadGameException {
    Game game = new Game(  );
    assertFalse("A new game should not be started yet", game.isPlaying(  ));
    game.shutdown(  );
}

With this approach, one test failure will not cause the remaining assertXXX( ) statements to be skipped.

This issue raises the question: should a test method ever contain more than one assertXXX( )? The answer is a definite yes! If you are testing a series of conditions in which subsequent tests will always fail when the first fails, you may as well combine all of the asserts in one test.

4.5.4 See Also

See Recipe 4.6 to learn how to create the Game object in the setUp( ) method and shutdown the game in the tearDown( ) method.