[rspec-users] Plain Text Story example

David Chelimsky dchelimsky at gmail.com
Thu Nov 8 06:58:47 EST 2007

On Nov 8, 2007 12:17 AM, Ben Mabey <ben at benmabey.com> wrote:
> David Chelimsky wrote:


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


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


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):


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:


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.


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


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


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


> Ben

More information about the rspec-users mailing list