|
»
»
« Return to Thread: Getting Started with Story Runner
Re: Getting Started with Story Runner
by Dan North
::
Rate this Message:
Hi James.
James Hughes wrote:
The reason there isn't a story "generator" is that the story and scenarios should evolve as the output of a conversation between the tester/analyst and developer. You start with a (failing) scenario which identifies your "outermost" objects - in this case an Account.
Then you drop into "traditional" TDD mode - or what we have started calling coding-by-example - to drive out the behaviour of the Account. Doing this you will probably discover other domain objects or services - say an AccountHolder or a BalanceTransferService - that you initially mock out to describe the behaviour of the Account.
Then you implement the AccountHolder and BalanceTransferService in the same way, discovering other objects as you go, until you have concrete versions of each of the players in the scenario.
Once these are all done, your scenario will work, and you're ready to move onto the next scenario. This is what I mean by outside-in, which is different from both top-down (a module-wise breakdown of functionality) and bottom-up (start adding behaviour to objects and worry about tying them together later on).
Right now, the story runner is less helpful than it could be (which is an ongoing conversation I'm having with David Chelimsky - short version, he's right).
The story runner should visit every step in each scenario. When the first step fails, it should carry on to all the subsequent steps and at least tell you what they are even if it doesn't execute them. That way you get the immediate feedback of failing fast, but you still see all the other steps in the scenario so you get a sense of context. Right now, it fails fast on the first failing step (which is correct) but it doesn't then carry on to tell you about the subsequent steps (which is wrong).
In reality, I find I run the scenarios quite often anyway to remind myself where I am and what the next unimplemented thing is.
Dan
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users
James Hughes wrote:
For a total noob you're right on the money!
Your code looks correct. My interpretation of the workflow that derives from this tool is that you write a high level story like you have here, run it, and let it tell you what to do next. The stack trace is telling you that you need an Account class. So now you would drop down to the object level and write a spec for Account (this is a Rails Story, so you'd write a model spec). Once you have that passing, you might come back up to the story level and re-run it, at which point it might tell you that it doesn't know about the balance() method on your account object; this would depend on how detailed you got in your model spec. I'm a total noob with this tool as well, so others on this list might have different insights;
The reason there isn't a story "generator" is that the story and scenarios should evolve as the output of a conversation between the tester/analyst and developer. You start with a (failing) scenario which identifies your "outermost" objects - in this case an Account.
Then you drop into "traditional" TDD mode - or what we have started calling coding-by-example - to drive out the behaviour of the Account. Doing this you will probably discover other domain objects or services - say an AccountHolder or a BalanceTransferService - that you initially mock out to describe the behaviour of the Account.
Then you implement the AccountHolder and BalanceTransferService in the same way, discovering other objects as you go, until you have concrete versions of each of the players in the scenario.
Once these are all done, your scenario will work, and you're ready to move onto the next scenario. This is what I mean by outside-in, which is different from both top-down (a module-wise breakdown of functionality) and bottom-up (start adding behaviour to objects and worry about tying them together later on).
Right now, the story runner is less helpful than it could be (which is an ongoing conversation I'm having with David Chelimsky - short version, he's right).
The story runner should visit every step in each scenario. When the first step fails, it should carry on to all the subsequent steps and at least tell you what they are even if it doesn't execute them. That way you get the immediate feedback of failing fast, but you still see all the other steps in the scenario so you get a sense of context. Right now, it fails fast on the first failing step (which is correct) but it doesn't then carry on to tell you about the subsequent steps (which is wrong).
You ping-pong at the granularity of a scenario. In other words, you get the scenario failing and then work inwards until you have all the moving parts to make the scenario work (and no more). Then you ping-pong up to the next scenario and work inwards again. It's more like a pulse than a ping-pong.I'd be interested in hearing other perspectives on how detailed you'd get the first time you drill down to the object level: would you spec out the object completely as specified at the high level and then verify that it satisfies the story, or would you keep ping-ponging back and forth between the two levels?
In reality, I find I run the scenarios quite often anyway to remind myself where I am and what the next unimplemented thing is.
Cheers,James
Dan
On 9/21/07, Evan David Light evan@... wrote:There are also a couple of examples buried in the trunk underexamples/story/game-of-life/behaviour/storiesOn Sep 20, 2007, at 10:13 AM, Andrew WC Brown wrote: I'm guessing their isn't a generator for stories yet? ./script/generate story add_person On 9/20/07, James Hughes < hughes.james@...> wrote:On 9/20/07, Ben Mabey < ben@...> wrote:Andrew WC Brown wrote:I haven't found any How To's to use story runner and I'm not surehowto get started. Should I be looking for resources on how to use rbehave? How do I generate my first Story?------------------------------------------------------------------------_______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-usersPat wrote up an awesome tutorial/example:http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runnerThat should get you started.This pastie may be of use as well: http://pastie.caboo.se/92472 James _______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-users_______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-users-- Monsterbox Productions putting small businesses on-line 1319 Victoria Avenue East Thunder Bay, Ontario P7C 1C3 Canada Andrew WC Brown web-developer and owner andrew@... P: 807-626-9009 F: 807-624-2705 _______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-users_______________________________________________ rspec-users mailing list rspec-users@... http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users
« Return to Thread: Getting Started with Story Runner
| Free embeddable forum powered by Nabble | Forum Help |
