[rspec-users] Role of stories vs specs

Pat Maddox pergesu at gmail.com
Tue Nov 13 18:17:27 EST 2007

On Nov 13, 2007 11:51 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Nov 13, 2007 1:10 PM, Pat Maddox <pergesu at gmail.com> wrote:
> > I've been thinking about the role that stories played compared to
> > specs, and that "should we use should" thread brought those thoughts
> > up again.
> >
> > First I want to discuss whether or not specs are authoritative
> > regarding the desired behavior of a system.  I would say they're a
> > good approximation of how the system currently runs according to the
> > developer's understanding.  I say they're an approximation because if
> > you use mocks everywhere (as I believe you ought to) then you're not
> > performing integrations and the specs are necessarily incomplete.
> >
> > Why does that idea matter?  Traditionally, we've leaned heavily on a
> > suite of unit tests to perform refactorings.  In fact, Fowler says the
> > first thing you have to do in order to refactor is grow a set of
> > comprehensive unit tests.
> >
> > Refactoring, by definition, is changing the structure without changing
> > the observable behavior.
> IMO, that definition refers to a system, not individual objects. When
> you change objects, you usually have to change the examples.

I agree completely.  That opinion is what spurred this line of thought.

> Keep in mind that that goes nearly unnoticed in java or .NET because
> of the refactoring tools available on those platforms. Change a method
> name once and it changes it everywhere, *including the examples*. Move
> a method from one object to another and you get a dialog that let's
> you opt to leave the existing method in place delegating to the new
> location, or change all the consumers of that method in the system,
> *including the examples*, to use the new location.

Which is fantastic, but what strategies should Ruby dudes use in the mean time?

> > If I say that stories are authoritative and specs aren't, then that
> > means I ought to rely on stories to provide the safety net for my
> > refactoring.  When taking those baby steps, it's important to keep the
> > stories green rather than the specs.
> On some level that makes sense - but it's going to slow you down quite
> a bit when you start building up a significant suite of stories.

That was my main concern.  You can get 1200 examples running in under
5 seconds.  Probably can't do that with stories.

> The way I've always dealt with this was to rely on the examples to get
> me through a refactoring, and then run the stories before committing.
> That allows me to stay focused on small problems and progress
> steadily.

Herein lies the (my) problem.  I find that when I refactor the
examples break.  You've already said that it's okay, because tools
ought to change the examples appropriately.  I don't personally have
an issue with breaking specs as I refactor...but that's because I've
learned to deal with it, and know what kind of breaking changes I'm
comfortable with.  My main point is that if I have to go in and
manually change specs, then in general I don't consider the specs to
be my comfortable safety net.  They'll get there when we have better
tool support, but I have to do stuff today.

I suppose the *real* problem is that I can't quantify what impact that
all has on my velocity.  So I just end up focusing on the pain that it
causes me.  But, I think getting rid of the pain is a very worthwhile
endeavor on its own.

> >  Another result of this thinking is that more specification should be
> > done in stories than I originally thought.  Edge cases are my prime
> > example.  I used to think I should write a story that expresses the
> > general desired behavior, and then cover any edge cases in specs.
> I think they should be covered in both stories and examples. The thing
> is that they get covered in different ways.
> For one, the language in which they are expressed is different -
> because the stories are about the system and the examples are about
> the objects in the system. And there will be some duplicated effort
> between the stories and the examples - and that is a GOOD thing.

Agreed.  The more-than-occasional-less-than-frequent duplication
between stories and examples doesn't bother me.  In my mind they're
completely separate systems, it's just that sometimes I happen to be
working on such a simple level that they appear to be the same.

> Additionally, when dealing with stories, you may specify that a
> particular error message shows up on the screen. However, when you get
> down to the individual objects, you would likely have a single example
> showing that the screen will show whatever error message you throw at
> it, and then move down to the model to generate this particular edge
> case message.
> > Finally, it's better
> > to keep all of the desired behavior specs in one place.
> Here's where we disagree. I think that it's a matter of who the
> audience is for the different tools.

Let's say in some banking software we have a transfer screen, and
there are three possible errors:  insufficient funds, source account
frozen, target account frozen.  Would you write a scenario for each of
the possible errors, and an example for each?  This probably isn't a
good example because I think you should :)  but it's easy to see how
it would lead to more duplication than I'm comfortable with.  Every
time you need to specify business value you have to stick it in a
story and an example.

> The vocabulary that we seem to be moving to in the trunk is this:
> Story Framework
> - Stories
> - Scenarios
> - Steps
> Example Framework
> - ExampleGroups (what you referred to as descriptions)
> - Examples
> I'm not completely comfortable with this yet in terms of being able to
> talk about it, so suggestions are welcome. The problem with using Spec
> or Example is that either can easily refer to the coarse grained
> stories or the fine grained object level examples. Maybe we should
> call them Coarse Grained Examples and Fine Grained Examples :)
> Seriously - I welcome other thoughts on this.

There's another part missing, which is the set of all stories, and the
set of all example groups.

> > What do you guys think?  Is it useful to draw a line and say that
> > stories are authoritative and specs aren't?
> I don't find this useful. To me they are two completely separate
> animals that work together to describe the behaviour of a system. They
> are equally authoritative (or not). They both have a life cycle in
> which they move from examples of what we'd like to examples of what we
> have.

I agree that they're completely separate beasts.  I have a feeling
we'll disagree on the point of what is authoritative.  I think that
stories clearly define how much of the system is done, and examples
don't do that at all.  However, I'm not sure yet if it's an important
distinction to make, and hopefully over the next few months I'll gain
deeper insight.

> Thanks for the thought provoking post!

Thanks so much for your reply.


More information about the rspec-users mailing list