On Nov 7, 2007 10:18 PM, Ben Mabey <[EMAIL PROTECTED]> wrote: > I just ran across this blog which helped me out a lot in answering some > of my questions about the plain text story runner: > http://www.kerrybuckley.com/2007/11/07/driving-selenium-from-the-rspec-story-runner-rbehave/
It's great to see this conversation advancing so quickly, however please keep in mind that this is all very young and just because someone blog's something (including ME) doesn't mean that it's "the way". While Kerry's example is very clean and obviously works well for him, it does go against the grain of the philosohy that Dan is espousing: expressing stories in the business domain rather than the UI domain (btw Dan, that was brilliantly put). In my own experience with tools like FitNesse, I've seen success and failure regardless of the level or focus of abstraction. In the end, what I think drives the success of tools in this (Acceptance Testing) space is the level of commitment and interaction that customers have with the tools and the stories they are expressing. These are called CUSTOMER Acceptance Tests, after all. And just as TDD is *for* developers, and you're probably doing TDD right if it keeps you productive throughout the life of a project (including the years of maintenance), the same goes for Stories - if the customer gets the way the stories are expressed and you are not finding yourself battling the environment or wasting time debugging your way through a labyrinth of test fixtures every time something changes, then you're probably on to something useful. > > The Selenium integration is also an interesting idea that you might want > to read about if you haven't seen this post. I'm still trying to > decided if using Selenium is worth the extra effort (my main goal would > be to test the JS during the acceptance tests) One cool thing about having the steps disconnected from the expression of the stories is that you can have more than one implementation of any given step and use the one you want based on any arbitrary runtime conditions. There is no direct support for making this decision built into the Story Framework, but this IS Ruby after all. This would theoretically allow you to write stories at an abstract level and decide whether to run each scenario in memory or in a browser based on whether or not there is additional business value in running them in browser. > and if the regular rails > integration testing is good enough. I'd be interested to hear what > other user's on this list think in terms of Selenium or any other > browser based framework and there experience with them. Generally speaking, in-browser tests tend to be incredibly brittle and run dog-slow. They simply have no choice but to be tied directly to low-level implementation details like html structure and element IDs. So I'd recommend only testing what you absolutely must in-browser. But given our ajax-laden world, "what you absolutely must" may well turn out to be a lot! FWIW, David > > -Ben > > > > Ben Mabey wrote: > > Hey all, > > Does anyone have an example(s) of the plain text story runner for > > rails? I have read David's blog > > (http://blog.davidchelimsky.net/articles/2007/10/22/plain-text-stories-on-rails) > > about it but I would like to see some examples with all of the step > > matchers included... I couldn't find any more examples on google > > talking about the plain text stories and the example rails app in trunk > > seems to still be using the other format. Does anyone have any links or > > pasties for me? Thanks, > > Ben > > _______________________________________________ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
