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