$row)") public void iToggleTheCellAt(int column, int row) { game.toggleCellAt(column, row); } @Then("the grid should look like $grid") public void theGridShouldLookLike(String grid) { assertThat(renderer.asString(), equalTo(grid)); } The code has a method for every type of clause in a scenario. JBehave will identify which method goes with which clause through the use of annotations and will call each method in order while running through the scenario. The text in each clause in the scenario is expected to match the template text given in the code for that clause (for example, a Given in a scenario is expected to be followed by a clause of the form "a X by Y game"). JBehave supports the matching of clauses to templates and has built-in support for picking terms out of the template and passing them to methods in the test code as parameters. The test code provides an implementation for each clause type in a scenario which interacts with the code that is being tested and performs a test based on the scenario. In this case: The theGameIsRunning method reacts to a Given clause by setting up the initial game grid. The iToggleTheCellAt method reacts to a When clause by firing off the toggle event described in the clause. The theGridShouldLookLike method reacts to a Then clause by comparing the state of the game grid to the expected state from the scenario. The primary function of this code is to be a bridge between a text file with a story and the code being tested. Note that the test code has access to the code being tested (in this case an instance of Game) and is very simple in nature. The test code has to be simple, otherwise a developer would end up having to write tests for his tests. Finally, in order to run the tests, JBehave requires some plumbing code that identifies the text files which contain scenarios and which inject dependencies (like instances of Game) into the test code. This plumbing code is not illustrated here, since it is a technical requirement of JBehave and does not relate directly to the principle of BDD-style testing. Story versus specification A separate subcategory of behavior-driven development is formed by tools that use specifications as an input language rather than user stories. An example of this style is the RSpec tool that was also originally developed by Dan North. Specification tools don't use user