At GeekNight last night, I spent a lot of time discussing JBehave’s story runner, and how it affects checkins.
When you parse a story and produce the template classes, they’re initially empty. Gradually they get filled in with mock objects. So, for instance, my Hellbound class’s main story, “As a Hellbound player, I want to play games so that I can improve my score”, starts with a scenario “Given that Hellbound is running, the game panel should appear when the game selection button is clicked.”
I mock the gui, and put a simple event handler in the Hellbound class that deals with a new game request by returning a new game report.
Next scenario: “Given the first scenario, a new shape should appear when I start the game.”
Now I need a real game, but I can manage with a mock shape factory. I need a real game factory. This is the point at which things get complicated enough to use PicoContainer. I’m still mocking stuff – the gui, and the shape stuff. I decide I need an event handling queue to manage thread issues between the gui and the engine. It doesn’t affect the story, but every class I create gets its own associated behaviour class.
Next scenario: “Given that I move the shape right, then rotate it, then drop it, then move the next shape left, then drop it, then rotate the next shape, then drop it, the line should be filled.” Well, JBehave doesn’t quite support this yet (give us time). I can start to use a real gui, though. I don’t have a gui shape component; that’s still mocked. Yet I don’t have any failing tests.
This is JBehave’s “amber bar”. Tests haven’t been written with real objects – they’re still using mocks. The story hasn’t been completed. It’s still OK to check in the code – no one else’s stuff has been broken. “That’s wrong,” one of the GeekNighters says. “You shouldn’t be able to do that. Red bar, green bar I understand… what’s with this amber bar?” The green bar is represented by a
., the red bar by
F for fail, and the amber bar by
M, meaning you’re still using mocks.
Well, the amber bar means that you haven’t finished implementing the story yet.
You get that in non-JBehave design too. You just don’t get to see it so clearly. Normally, the only place you keep track of how much of a design you’ve implemented is in your head, or in the number of task cards you’ve marked as complete, or in the amber bar of some kinds of XP planning software… oh, wait. Now it all makes sense.