[rspec-users] Role of stories vs specs

Pat Maddox pergesu at gmail.com
Tue Nov 13 14:10:38 EST 2007


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.  Implicit in using tests to enable
refactoring is the idea that those tests precisely define what the
behavior of a system should be.  If we say that our specs are not
actual specifications of desired behavior, then specs aren't
sufficient safety nets for refactoring.

This mostly comes from my experience that refactoring is often a PITA
when using mocks.  Mocks isolate dependencies, which is great, and
makes it easy to change code without affecting parts of the system
that really shouldn't be affected.  However they make simple, standard
refactorings like "move method" more difficult.

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.

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.
However edge cases should be covered by stories because stories define
the desired behavior of the system.  Also, edge cases presumably
represent some business value to the customer.  Finally, it's better
to keep all of the desired behavior specs in one place.  Stories are
naturally more verbose than specs though.

That paragraph feels awkward to me, because I think I'm missing some
vocabulary.  It suggests to me that the collection of all user stories
is the app specification - "spec" for short.  What is the collection
of all descriptions, the object-level specs?  I've always just said
"specs," but I don't think that really fits anymore with my current
thinking.  Not to mention it's just confusing if I also use "spec" to
mean the collection of all user stories.  I know that an individual
describe block is a "description," but maybe the whole suite should be
called "descriptions" instead of "specs?"

What do you guys think?  Is it useful to draw a line and say that
stories are authoritative and specs aren't?  Do you think it becomes
less crucial to use object-level specs to enable refactoring, and
instead lean on stories more?

Pat


More information about the rspec-users mailing list