I've been using story runner for the first time over the past 4 months or so and I've found the invaluable part to be the plain text support. Having a shared artifact that can be used by the customer, developers and testers is a huge boost towards achieving ubiquitous language. We use the story kickoff discussion to refine the language used in each scenario together, ensuring that the language makes sense to everyone and is consistent with other stories.
In the sense that we want a way to store the feature/story in an executable format that we can all understand, a tool that supports plain text stories is the best choice for us. You can implement a scenario just as easily using plain rspec but then it becomes less accessible to other people in the team. If I was choosing a testing approach for a project that had technical people as customers I would still use the GWT format. I think it helps you continually focus on what you are really trying to achieve, otherwise it can be too easy to burrow down into the technical details and lose sight of that. No matter what the nature of project, every thing that you do is driven by the goal of adding some sort of value. Continually keeping that goal in mind helps you make better choices along the way. I agree with James that having that separation between the "what" and "how" is very useful. This approach is amenable to a more black box style of testing appropriate for acceptance tests. You should theoretically be able to completely change how your system works without touching the story/feature text. Your mileage would of course vary with this depending on whether or not you use a more declarative or imperative approach (as Ben describes in http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/ ). My current recipe for testing spread is to automate the acceptance scenarios using a tool like story runner/cucumber and then use specs for targeted integration and unit level testing. The automated acceptance scenarios cover the main scenarios that the customer cares about while more specialised cases (or more technical aspects) are covered at the spec level. The specs will typically gravitate towards the white box end of the scale (describing the internals in more detail). - Brent
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
