I’ve learned the value of dealing seriously with connecting requirements to the actual code. The JBehave project started work to make formal, “business friendly” requirements into executable specifications, but due to limitations in Java, it was very clunky to use. JBehave 2.0 has just been released, and it has a much better model.

Here’s a specification:

Story: Play Tabs

As a music fan
I would like to convert guitar tabs to music
So that I can hear what they sound like

Scenario: My My Hey Hey
Given tab
e|---------------------------------
B|---------------------------------
G|---------------------------------
D|----------0--0-------------------
A|-0--2--3----------2--0-----0--0--
E|------------------------3--------
When the guitar plays
Then the following notes will be played
A0 A2 A3 D0 D0 A2 A0 E3 A0 A0

The scenario is connected to Java code. While JBehave 1.0 used anonymous inner classes to do this, JBehave 2.0 uses annotations:

public class PlayTabSteps extends Steps {
 
@Given("tab $asciiTab")
public void tab(String asciiTab) {
}
 
@When("the guitar plays")
public void guitarPlays() {
}
 
@Then("the following notes will be played $notes")
public void theFollowingNotesWillBePlayed(String notes) {
}
}

For more, see Ray Greenhall’s tutorial. The tutorial is good, but it suffers from an unintended large weakness: The second half of the tutorial contains the convoluted design that is often the result of overuse of mock objects. The last year, I have spent more time removing mocks from code than actually using mocks, and I’m just about fed up with mock-ish design.

Can you spot the nefarious effect of the mocks on the design? How would it have looked if the example had followed The Simplest Thing That Could Possibly Work?

(Still: A very good introduction to a promising new tool)