8.5 JUnit, Fixtures, Assertions & Test Doubles

Theory: JUnit, Fixtures, Assertions & Test Doubles

TDD needs a tool that can run hundreds of small tests in seconds, every time the code changes. For Java that tool is JUnit. This lesson covers what JUnit is, how fixtures give every test a clean start, the order in which JUnit runs annotated methods, the main assertions, how tests are grouped into suites, and the family of fake objects called test doubles.

What JUnit Is

JUnit is a free, open-source unit-testing framework for Java, written by Erich Gamma and Kent Beck. It is a code-level regression testing tool: once written, the tests can be re-run automatically after every change, so any behaviour that breaks is noticed at once. Many languages have similar tools in the same family (PHPUnit for PHP, and so on). The latest version is JUnit 5; the slides use JUnit 3 and JUnit 4.

Fixtures: Set the Table Before Every Guest

A good restaurant does not let the next guest sit down at a table covered in the previous guest’s plates. Before each guest arrives, the table is set the same way: clean cloth, knife, fork, glass.

A fixture does the same for tests. It creates the objects and initial values that several tests need, so that every test starts from the same known state.

Fixture: the set-up (objects and initial values) that puts every test into the same known starting state. In JUnit 4 it is usually built in a @Before method, which runs before each test.

This is exactly the “every test starts fresh” rule from 8.1: a fixture removes any chance of one test depending on a side effect of another.

The Order of the Annotations

JUnit finds the methods to run by their annotations and runs them in a fixed order:

In one line: @BeforeClass → ( @Before → @Test → @After ) repeated → @AfterClass.

The part in brackets repeats once for every @Test method. These are the JUnit 4 names; JUnit 5 renamed them:

Example: AccountTest (JUnit 4)

import org.junit.*;
import static org.junit.Assert.*;

public class AccountTest {
    private Account acc;

    @Before
    public void setUp() {
        acc = new Account(100);            // fixture: a fresh account before EACH test
    }

    @Test
    public void depositAddsMoney() {
        acc.deposit(50);
        assertEquals(150, acc.getBalance());   // (expected, actual)
    }

    @Test(expected = IllegalArgumentException.class)
    public void negativeDepositIsRejected() {
        acc.deposit(-50);                  // passes only if this throws
    }
}

Because setUp() runs before each test, negativeDepositIsRejected gets a brand-new account with balance 100, whatever depositAddsMoney did, and the two tests can run in any order.

JUnit 3 vs. JUnit 4

The Main Assertions

Note the argument order: expected first, actual second. Swapping them still compares the same values, but the failure message (“expected 140 but was 150”) then reads backwards. The delta version exists because decimals are stored inexactly: 0.1 + 0.2 is not exactly 0.3 in a double.

From the slides: two traps.

1. If you write your own equals for a class, its parameter must be Object: public boolean equals(Object obj). If you write equals(Person p), you have overloaded rather than overridden equals, and assertEquals will not use it.
2. assertEquals checks equal values; assertSame checks the same object. Two different Person objects with the same name can be equal but are not the same.

Test Suites

A test suite runs many test classes together:

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(Suite.class)
@SuiteClasses({ AccountTest.class, TransactionTest.class })
public class AllTests { }   // empty: it only holds the annotations

Test Doubles

A test double is any object that stands in for a real one during a test, like a stunt double stands in for an actor. The general idea is the stub of 8.2; the vocabulary distinguishes five kinds:

The professor mentioned mocks and dummies only briefly; know the idea that each is a stand-in with a different amount of behaviour.

Worked Examples

public class StackTest extends TestCase {
    private Stack s;
    protected void setUp() { s = new Stack(); }
    public void testPopEmptyThrows() {
        try { s.pop(); fail(); } catch (EmptyStackException e) { }
    }
}

import org.junit.*;
import java.util.EmptyStackException;

public class StackTest {
    private Stack s;

    @Before
    public void setUp() { s = new Stack(); }

    @Test(expected = EmptyStackException.class)
    public void popOnEmptyStackThrows() {
        s.pop();
    }
}