Hi Andy, This is how I think of Stories and Behaviour.
- A Story provides value to a Customer. - Behaviour provides value to other code, or to the Story / Customer directly (eg: the Gui). So, what I normally do is: - Get the story from the customer - Describe the story in code. - Work out the first class which will give value to the Story (eg: the Gui) - Describe the behaviour for that class, mocking or stubbing any dependencies, and perhaps creating some domain objects - If I create any domain objects, I will describe their behaviour too - even if the behaviour methods are empty for now in which case I can just add "todo()" in their body. - Implement the behaviour - Create behaviours for any dependencies I've mocked out, or domain objects, mocking out any of their dependencies - Implement the behaviour etc. Eventually I will get to a point at which the Story executes correctly. Then I can take on the next Story. A few notes about how this works in reality: - I only work on 1 Story at a time, but I may have many stories waiting. - I often have 3 behaviours on which I'm working at a time; todo() really helps here. - I usually concentrate on one piece of value at a time, so if I need the Game to respond to the Down button, I'll worry about the Left and Right buttons later. - Whenever I can't remember how far I've got, I'll run the Story. The first Story usually requires a bit of up-front design, which I discover as I start to write the behaviour for the Gui, then the engine behind it, etc. This is kind of like the first application spike. Last time I wrote a story like this - the first glyph is displayed in the pit - I deleted it as soon as I had a second story that required it. It now exists only as a GivenScenario. Cheers, Liz. -- Elizabeth Keogh [EMAIL PROTECTED] http://sirenian.livejournal.com http://jbehave.org
