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:
Post a Comment