[rspec-users] Plain Text Story example

Glenn Ford glenn at aldenta.com
Fri Nov 9 14:29:59 EST 2007


That was exactly what I needed, thanks a lot!

Glenn

On Nov 9, 2007, at 10:59 AM, Dan North wrote:

> Hi Glenn.
>
> On Nov 8, 2007 4:01 PM, Glenn Ford <glenn at aldenta.com> wrote:
> It seems that what I'm coming to understand of the direction of this
> story concept is that there is a lot of emphasis being put on ensuring
> we keep things at the business level.  I can appreciate the elegance
> of it certainly, but when I think of what I would really want to gain
> from this story-based testing process, I feel like it cuts out room
> for some really cool ideas.  Maybe you can help me see where they
> would fit.
>
> I have in mind a scenario where a customer says "I tried to log in and
> it blew up!"  I take what they say with a business perspective and
> check my story and say "hey I've got a login story and it works" but
> that doesn't leave room for the fact that, slighty away from the norm
> of the usual login procedure, this particular user clicked another
> link in the middle of the process that changed some background
> variable, breaking the process at the final login step.  I would then
> want to write a story similar to the usual login, but with the ACTUAL
> details of what the customer did to ensure I could duplicate, fix, and
> then never have this problem creep up again.
>
> I completely agree.
>
>  My story, in order to be
> of use to me, would HAVE to have steps like "click this button"
> because, quite frankly, as a developer I find that's the sort of thing
> that can break my code and so I would want a story to account for it.
>
> Yes, exactly. In this example, the UI domain is the most useful  
> domain to express the (bogus) behaviour, so it's the right thing to  
> do. The scenario might be something like:
>
> Scenario: press the Explode button whilst filling in form
>
> Given I navigate to the Submit order page   [I'm loving these infix  
> parameters!]
> And I set first name to Dan and second name to North
> When I click the Explode button
> Then nothing should happen
> And the current page title should be Submit order
>
> Now, the whole of this scenario is in UI domain terms. It doesn't  
> matter what business function I'm trying to achieve here - the  
> description is about some bogus behaviour in my implementation (the  
> Explode button should be disabled whilst I'm capturing data)
>
> So it's fine to express scenarios in either business domain terms to  
> describe actual business flow, or UI terms to describe the user's  
> interactions with the application. The confusion starts when you mix  
> the two domains in the same story or at least in the same scenario.
>
>
> A user following my intended user-flow, then deviating in a way I
> didn't predict.  From the business end, they still followed the login
> process, they just had one little different quirk along the way.
>
> Yes, and it's that quirk in this particular UI that you want to  
> capture with this scenario.
>
> Is there a way to get this kind of thing but still keep to the ideal
> business perspective?
>
> You're trying to do a different thing here. The audience is  
> different (probably a tester or UI designer rather than a business  
> stakeholder) and they'll be using a different vocabulary.
>
> Would I just simply "word" it in a way that the
> simple little thing they did had a business description?  Or is that
> an indication that I have stupid things on my page that shouldn't even
> be an option?  Or is there a "happy medium" here as well between
> business and ui perspectives of stories?
>
> See above - as long as you keep the distinction between domains when  
> you are describing a scenario, you'll probably be ok.
>
> Glenn
>
> Cheers,
> Dan
>
>
>
> On Nov 8, 2007, at 6:58 AM, David Chelimsky wrote:
>
> > On Nov 8, 2007 12:17 AM, Ben Mabey <ben at benmabey.com> wrote:
> >> David Chelimsky wrote:
> >
> > <snip>
> >
> >>> ... 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?)
> >
> > Sorry - there are two different threads going on about this topic
> > right now - the other one is on the rspec-devel list and that was
> > where Dan posted that statement:
> >
> > http://rubyforge.org/pipermail/rspec-devel/2007-November/004259.html
> >
> > Keep in mind that User Stories are oft described as "a token for a
> > conversation", and that even with acceptance criteria spelled out,
> > whether the button says "Create New Account" or "Enter" is rarely of
> > sufficient business value to express that in a story. That's the  
> sort
> > of detail that comes out when you say to your customer "the entry  
> form
> > is done, why don't you come by so I can show it to you," as  
> opposed to
> > in the iteration planning meeting.
> >
> > In the end it really does boil down to what the customer feels is
> > necessary in order to accept the software. If the customer really  
> DOES
> > care about what the button says, he or she may want that expressed  
> in
> > a story. But even then, saying "And I press Create New Account"  
> still
> > leaves things flexible enough so that you could be describing a web
> > app, a GUI app, a touch-screen app, etc. The only thing this doesn't
> > work for would be a command line app. So maybe "And I tell the  
> system
> > to Create New Account" would leave room for that as well. Or maybe,
> > "And I fold my arms and command the system to Create New Account." I
> > kinda like that one!
> >
> >> 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?
> >
> > Unless the business IS software, like a text editor, yes.
> >
> >> 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.
> >
> > Ah - confusion. I DO like to spec my views first - when I get down  
> to
> > the Spec Framework.
> >
> > In our example at RailsConf EU, we talked about a Cup Tracker (as in
> > Rugby, which was going on at the time). Take a look at the example
> > story:
> >
> > http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter1/stories/plan_cup.rb
> >
> > This story really rides this whole line very nicely. We're  
> describing
> > software that presents a view of something abstract, and we do so  
> with
> > some detail about what it presents - but there is nothing in it that
> > says "when I click this button" or "when I enter this text."
> >
> > Now look at this version (same story, w/ the steps filled in):
> >
> > http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/stories/plan_cup.rb
> >
> > Note how the implementations of the steps are starting to get into  
> the
> > views. That's where that level of detail starts to play out.
> >
> > Now look at this:
> >
> > http://rspec.rubyforge.org/svn/branches/railsconfeu2007/tags/chapter4/spec/views/cups/show.rhtml_spec.rb
> >
> > That spec was arrived at with the very granular red-green-refactor
> > process of TDD with a focus, naturally, on behaviour, design and
> > documentation (It just occurs to me that behaviour, design and
> > documentation are B, D and D - interesting ...).
> >
> > Now some people look at that spec and scream "holy crap - look at  
> all
> > the duplication - all that mocking - so brittle!." I won't disagree
> > that there is lots of duplication with other parts of the system, a
> > lot of mocking, and changes to the views would require changes to  
> this
> > spec (brittle). And, looking back at this, I might want to break  
> that
> > spec up into more granular examples. While it speaks very well  
> looking
> > at the code, running it would only tell you that "/cups/show.rhtml
> > should display the chart."
> >
> > But check this out! The implementation of that spec, with all that
> > mocking, IS the spec for the controller and model. That single spec
> > tells us about the structure that the model should expose (NOT the
> > actual structure necessarily - just what it should expose to things
> > like views that want the models to be easy to use) and what the
> > controller should provide for the view.
> >
> > So this is all about discovery - starting from the outside and  
> moving
> > in. Implementing the steps that describe domain concepts help us to
> > discover some details of the views. Implementing the view specs help
> > us to discover the services we want from our controller and the APIs
> > we want from our model. I find that to be very compelling.
> >
> > <snip>
> >
> >> 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?
> >
> > Well, they should drive every aspect, but not directly. You're not
> > going to describe database table structure in your stories, but in  
> the
> > end those structures end up as they do because of the stories.
> >
> >>>> 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)
> >
> > <snip>
> >
> >>> 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!
> >
> > <snip>
> >
> >> 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,
> >
> > My pleasure!
> >
> > Cheers,
> > David
> >
> >>
> >> Ben
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20071109/9fbc7260/attachment-0001.html 


More information about the rspec-users mailing list