Tyburn is a fast, minimal, extensible Java Swing harness that was originally part of JBehave 1.0. You can download it here and use it like this:


WindowControl control = new WindowControl("my.named.frame");
control.clickButton("a.button");
control.enterText("a.textfield", "Text1");


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…

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.

So was our Business Analyst. “So, this story that was estimated at 3 days,” she said. “Can I say it’s only taken one?”

“No! We’re not done yet!” I protested.

“Really? It looked like you were almost done on Friday… what happened?”

Oh, well. At least we know it looks good.

“We’ll need to create this domain object,” she said, “and a database table.”

“I don’t want to do that,” I said. “I’d rather fix the stuff that’s broken.”

She looked puzzled. “What do you mean? We haven’t written any code yet.”

“Well, we know that if you go to the URL, you should see the form. But when I go there I get a 404 error.”

“Well, yes. We haven’t written any code yet.”

“So, it’s broken. It doesn’t work yet. We should fix that.”

So we wired up the container and knocked out a controller. We restarted the server and refreshed the URL. Spring told us we had left out a couple of things. We fixed those.

Negin tapped something into the template and refreshed the URL again. “We have a page. It says HELLOOOOO! across the top. Now what?”

“Well, we got rid of the 404 error. But the page doesn’t look right.”

“Of course not. We haven’t written the form yet.”

“We should fix that.”

We wrote the form. It didn’t look right, so we added the styling. Our business analyst peered over our shoulders at what we were doing. “Looks like you’re doing well. Why doesn’t the drop-down have my data in?”

Negin said, “You’re right. We should fix that. This is fun!”

“It is,” I said. “Don’t you just love that we get paid for this?”

public class PrimaryMixingIteratorTest extends EasyMockObjectTestBase{
    public void testShouldIterateLikeAFox() throws Exception {
        //...
    }
}

public class SecondaryMixingIteratorTest extends EasyMockObjectTestBase{
    public void testShouldIterateLikeABadger() throws Exception {
        //...
    }
}

Once I’ve remembered how foxes and badgers iterate, this code might make more sense to me. Remind me to run that ‘should is not a silver bullet’ brown bag soon…

Update: If you tied a fox and a badger together and dropped them into the corner of a square pond, they’d make a splash. Imagine that splashes happened in squares instead of circles, and that the quarter of the concentric square formed by the fox and badger started at the top-right then went to the bottom-right then bottom-left. Now imagine that the fox shouts out which row the splash happens in, and the badger shouts out the columns.

It’s a way of combining the values of two infinitely-sized lists for an arbitrary number of combinations, without loading the lists into memory. Makes so much more sense. Hold on, I’m getting a phone call from the RSPCA…