Liz Keogh's blog

svn co http://svn.codehaus.org/jbehave/trunk

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…

If you’re more interested in the results than the conversation, skip to the summary.

Recently, I’ve realised that a lot of BDD has been very dev-focused. There’s a reason for that. Dan’s a dev, I’m a dev and most of the people who helped to evolve BDD are devs.

BDD’s about the interaction between the business and the technical people in software. I want to know how it’s working from the other side. So, I’ve been learning more about the customers, and particularly, more about BAs and their role. I had the recent fortune to run into Angela Martin at Agile India, where she taught me the art of grouping stories into coherent releases, while still keeping the stories granular enough that progress can be measured and delivery made regular and predictable.

Last night at XtC I met up with Chris Matts (of Real Options fame) who told me we’re doing it all wrong. “It’s not an art, it’s a process,” he said. “You’re focused on the stories; that’s why you think it’s an art form. The focus should be the value you’re releasing.”

“Right”, I say. “So, when we originally planned the stories that would deliver the value, we knew what would contribute to that value. But we’ve lost sight of that. Changes have been made. As devs, all we have are those narratives – the ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’. So we need to work out which of the benefits add up to the value we’re aiming for. That helps us work out which stories we should try to complete for a release. The QAs are helping us work out what’s ready; the BAs are helping us work out what’s important.”

“That’s the problem,” says Chris. “You’re putting the role first. It’s the value that’s most important. Try this: In order to <deliver some value>, as a <role>, I want <some feature>. Instead of working out why people want a feature, and whether it contributes to the value, now we’re working out who needs a feature, then assigning the story. So our stories are much more focused. If all the stories that contribute to a value are ready, we release.”

I guess if we get to the point where we can release with only some of the stories ready, we didn’t break down our values into granular enough elements. And when we want to work out what goes in a release, it’s easy. The word ‘release’ is more meaningful. There’s some untapped money out there – some market share, some cost saving, some battle against a competitor. All the features we produce go towards releasing that value for our customers to use – and it’s the value we’re releasing, not the features.

Thanks, Chris, for that.

I need to also thank Dave for giving me a better understanding of what a value is.

In summary: my preferred narrative now reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Because, in order for my work to have any meaning, as a dev, I want to know why you want it.

Edit: Chris said he posted this to the Kanban group on Yahoo, but they aren’t responsible for it. Sorry, Chris, didn’t mean to misaappropriate! See you on there soon.