Thursday, January 22, 2009

BDD v. TDD: an example

Following up on my last post, one of my secondary goals in talking about fluent interfaces for testing in Java is to showcase the difference between a traditional TDD approach and a BDD approach:

// In SamTest.java
@Test
public void testIsVisibleAfterGettingTheOneRingAndWearingIt() {
    sam.getItems().add(THE_ONE_RING);
    try {
        THE_ONE_RING.setWorn(true);
    } catch (final GameOverManException ignore) {
    }
    assertThat(sam.isVisible(), is(false));
}

// In TheOneRingTest.java:
@Test(expected = GameOverManException.class)
public void testSetWornForSam() {
    new Sam().getItems().add(THE_ONE_RING);
    THE_ONE_RING.setWorn(true);
}

Contrast:

// In WhenPossessingTheOneRing.java:
@Test
public void samShouldBeInvisibleAfterWearingIt() {
    assertThat(sam().after().gettingTheOneRing().and().puttingItOn(), is(
            not(visible())));
}

@Test
public void samShouldNeverWearIt() {
    assertThat(sam().after().gettingTheOneRing().and().puttingItOn(), is(
            corrupted()));
}

(Given, of course, a suitable fluent testing DSL. Opinion question: I put the DSL in PosessingTheOneRing.java and followed the convention of naming the support class by dropping When from the test class name. Is this good practice?)

No comments: