[rspec-users] Plain Text Story example

Ben Mabey ben at benmabey.com
Thu Nov 8 01:17:55 EST 2007

David Chelimsky wrote:
> On Nov 7, 2007 10:18 PM, Ben Mabey <ben at benmabey.com> 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).
What exactly do you and Dan mean when you say that the stories should be 
expressed in the business domain rather than the UI domain?  (BTW, is 
there a link to a Dan North post abou that?)  From my understanding you 
are saying that the steps that say "user types in such and such" and 
user "hits the login button" are too UI specific and don't really have 
much to do with the business domain.  Is that correct? 

I think that this is a part of writing stories that I am somewhat 
struggling with, meaning how specific should these stories be in 
explaining the view?  At RubyConf during your presentation (great job, 
BTW!) you mentioned how you like to spec out your views first.  I agree 
that is is a really nice way to drive the development process.  Now with 
the introduction of the story runner we are now letting the stories 
drive the process.  So my thinking is that you let the stories drive all 
of the development, including that of the views.  Is this assumption 
wrong?  This feels right in one way because I will not be adding a form 
to a view unless the story specifies it and thereby drives BDD... On the 
other hand this level of granularity seems a bit overkill and clutters 
the stories a bit.  Where is the happy medium, in your opinion, between 
keeping the stories concise and letting them drive every aspect of the 
development?  Maybe I am wrong in saying that the stories should drive 
EVERY aspect of the development?

>> 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.

Yes, good point.  The step matchers really do open up a whole new world 
of possibilities.
>> 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!
> David
I have heard that Selenium suites can become out of hand and end of 
being more hassle than what there worth.  Thanks for the recommendation, 
I think that sounds like a sensible one.  

Thanks for taking the time to discuss this,


More information about the rspec-users mailing list