Big thanks to Dan North, Chris Matts, David Anderson, Amr Elssamadisy and the amalgam of developers who make up “Jerry”; also to the Thoughtworkers who reviewed my article and gave me advice, and the Kanbanjins like Eric Willeke who patiently talked me through Lean and Kanban. Several times. Anything I still haven’t understood is my error, not theirs.

I wish I could have put in everything I’ve learnt about Kanban, which is far larger than this article allows. It strikes me as a lovely, simple, high-discipline, least-wasteful way to deliver software, and it matches my feeling that you should fit your process to reality, not reality to your process.

My experiments with Kanban boards so far have been highly successful. Now I want to know about the problems, too. Have you tried Kanban? What happened? Did you try to introduce it? Did that work out? If not, why not? Did you think about introducing it, but decide not to? Tell me your stories!

I loved the ease with which you could combine smaller steps to make bigger ones, use scenarios as the contexts of further scenarios, and take the necessarily procedural automated tests and turn them into sets of reusable objects.

Now BDD is more widely used, and people out there are using JBehave 2 and RSpec, and I hear complaints. Amongst them, this is one of the more common:

“Every time I change this screen, I have to go through fifteen files and add another step.”

Since JBehave uses plain text scenarios you can’t rely on the common refactoring tools, and that can make it a bit more painful than just messing with code. So, I thought I’d have a go at explaining how I avoid this issue; by sharing some of the ways in which I divide or combine contexts, events and outcomes into reusable components that help me avoid duplication in my scenarios.

Given a context

A context is a state which was set up by irrelevant forces, and which is used within the scenario to alter the outcome resulting from the events.

If the manner or time in which the context was set up matters, then that, too, is part of the context; unless it’s part of the behaviour you’re looking for, in which case it’s an event. The only reason for separating the contexts in which a scenario occurs from the events which are performed in the scenario is because it doesn’t matter how they were created. This means that Givens have more flexibility in implementation than Whens.

A context should matter. If you can remove the context from the scenario without changing the outcomes, it isn’t part of the Givens.

A context should be independent of other contexts. So, I prefer Given a wet newspaper to Given a newspaper / Given that the newspaper is wet. The first is less likely to require refactoring than the second.

A context should create an abandonable artifact. By this I mean that the forces which created the artifact – data in the database, files on the disk, a particular page at a given URL – can safely forget about the context they’ve created. Given an article about Iraq is a good context. Given I am logged in is not so good, even though we frequently use it as an example. Sorry. If it helps, it’s a step that rarely needs maintenance. Given we’ve filled in the comment box and are ready to submit it is likely to cause issues, because of all the other tiny steps that you have to use to get there.

When an event happens

An event exercises the feature whose behaviour you’re interested in when describing or running the scenario.

If you don’t care whether it works as long as it leaves things in a clean state, it’s a context. If you don’t actually need to do anything to cause an outcome – you’re simply checking that given some state, some other state is also present – you don’t need to write an event; just skip straight from Given to Then.

An event should create a valuable outcome.The granularity of the ideal event is very similar to that of the ideal context. As a user, I don’t want to go to the screen with the book, click the purchase button, navigate to the basket, enter the credit card number and click “submit”. I just want to buy a book. By specifying the steps which a user purchases a book inside the granularity of this larger step, we capture the value of that step. Since people rarely do things that they (or their sponsor, paymaster, loved one, etc.) don’t find valuable, this can usually be reused as one large step.

An event may be dependent on context or on another event. So, when I buy a book, and when I cancel my order within 15 days, then I should not be charged for the book.

An event should cause or contribute to an outcome. The outcome is something measurable. It could be that the outcome you’re looking for is an absence of something, for instance if a user’s preferences have been changed, and you no longer want to see all those Facebook groups. If it doesn’t cause an outcome, it’s a fairly irrelevant event.

Then an outcome occurs

An outcome describes the benefit that your system or application provides when the events are performed in the given context.

An outcome should have teeth. If a particular error message doesn’t have the exact wording expected, the world will not come to an end. If my credit card gets billed for the books but I don’t get them when I expect, it might.

An Outcome should be Specific, Measurable, Achievable, Relevant and Timeboxed. Ask a QA if you don’t know what this means. QAs are wise and can break anything.

An Outcome should represent the valuable purpose of the events. Instead of checking that a series of menus exist when you navigate to a particular screen, write a scenario that uses those menus and check that the benefits they provide are accessible through them.

Stories and regression tests

It can take quite a while to run scenarios. I sometimes like to turn mine into regression tests by combining them. I like to add contexts, events and outcomes to existing scenarios to better describe the benefits of using any particular feature in any particular context. This may mean that scenarios are related to more than one story. This will help keep them maintainable, and isn’t a bad thing.

I have never found the need to add a context to a scenario half-way through that scenario, even if it’s been created from several others.

I do frequently use one scenario as the context for other scenarios.

Unteaching the business

Sometimes, we accidentally train our business to talk to us about the solutions they’d like, occasionally in the language of software development. In that case, they’ll quite happily discuss the particular steps they need to take in the GUI to achieve the desired outcome, and may even have an idea of the underlying database tables and discuss what ought to be in those tables after the events.

If this happens, try to draw the conversation back to how the data will be used; why it’s valuable to produce that artifact in the first place. You never know; you may find you need to do less work than you thought you did.

Our goal with JBehave 2 was to make the process of collaboration, drawing up scenarios and getting started easy and simple. Feedback from enterprise users suggests that we may have succeeded!

Find out more about the new features, the ones we’ve discarded, and how to use it on the JBehave site.

No ‘official releases’ yet, but if you want to play, go ahead. Examples of examples are checked into trunk.

Features include:

• plain text scenarios
• steps defined using annotations that match the scenarios
• built on JUnit
• Ensure (which is just an extension of Assert, so you don’t have to use it)
• auto-conversion of string arguments to numbers
• pending steps generated for anything which hasn’t been defined yet (these don’t break the build)
• errors from scenarios are rethrown after the full scenario has been described

Our goal with JBehave 2 was to make a framework that was lightweight, easy to use and didn’t take as long to set up as JBehave 1. To that end, we’ve been driving this entirely from example code – no guessing, unless it’s obvious – and we’ve ended up with something that works quite a lot like RSpec’s story runner, but for Java.

• To use it, simply name your scenario file with underscores, eg: i_can_toggle_a_cell and define steps in it thus:

  Given a 5 by 5 game
  When I toggle the cell at (2, 3)
  Then the grid should look like
  .....
  .....
  .....
  ..X..
  .....
  When I toggle the cell at (2, 4)
  Then the grid should look like
  .....
  .....
  .....
  ..X..
  ..X..
  When I toggle the cell at (2, 3)
  Then the grid should look like
  .....
  .....
  .....
  .....
  ..X..

• Then extend the Scenario class with a similarly named Java class:
  ICanToggleACell.java
• Extend the Steps class – this is where your steps will be defined, and you can have as many as you want
• Inject these into the Scenario:

  public class ICanToggleACell extends Scenario {
  
  	public ICanToggleACell() {
  		super(new GridSteps()); // varargs, can have lots of steps
  	}
  }

• Annotate methods in your step class to match the ones in your plain text scenario.

  public class GridSteps extends Steps {
  
  	private Game game;
  	private StringRenderer renderer;
  
  	@Given("a $width by $height game")
  	public void theGameIsRunning(int width, int height) {
  		game = new Game(width, height);
  		renderer = new StringRenderer();
  		game.setObserver(renderer);
  	}
  
  	@When("I toggle the cell at ($ column, $row)")
  	public void iToggleTheCellAt(int column, int row) {
  		game.toggleCellAt(column, row);
  	}
  
  	@Then("the grid should look like $grid")
  	public void theGridShouldLookLike(String grid) {
  		ensureThat(renderer.asString(), equalTo(grid));
  	}
  
  }

• Run your new scenario!

Future features we’re thinking of:

• having more than one scenario in a file
• tagging scenarios
• better tolerance of whitespace
• an option for pending steps to break the build
• decent documentation to show you how you can customise filename parsing, argument parsing, etc.
• anything you persuade us you need.

Give it a go and tell us what you think! Release 2.0 can’t be far away…

Peter’s mentioned JBehave 2, so the secret’s out now – yes, it’s in progress. It’s not publically available because it’s just a spike at the moment. We’re starting afresh, learning some of the lessons that made JBehave 1.0 hard to use, taking advantage of JUnit 4’s features, and drawing heavily on the success of RSpec.

Our goals for JBehave 2 include:

• no internal support for mocking – should be able to use any of the libraries
• extends JUnit – right-click and run both behaviours and scenarios
• uses Hamcrest’s matchers
• uses plain-text scenarios à la RSpec

Here’s a sneak preview of the spike so far.

We have a scenario file, i_can_toggle_a_cell:

Given a 5 by 5 game
When I toggle the cell at (2, 3)
Then the grid should look like
.....
.....
.....
..X..
.....
When I toggle the cell at (2, 4)
Then the grid should look like
.....
.....
.....
..X..
..X..
When I toggle the cell at (2, 3)
Then the grid should look like
.....
.....
.....
.....
..X..

We have a small class in the same package to run this, called ICanToggleACell.java (the Scenario class is a JUnit test):

package com.lunivore.gameoflife;

import org.jbehave.scenario.Scenario;

import com.lunivore.gameoflife.steps.GridSteps;

@SuppressWarnings("unchecked")
public ICanToggleACell() {
super(new GridSteps());
}
}


And we have steps defined thus:


package com.lunivore.gameoflife.steps;

import static org.hamcrest.CoreMatchers.equalTo;
import static org.jbehave.Ensure.ensureThat;

import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.steps.Steps;

}


I’m excited that this actually works. The next step is to get appropriate error messages when the scenario fails! We’re working hard to get this out to you as soon as we can; watch this space.