[rspec-users] Role of stories vs specs

David Chelimsky dchelimsky at gmail.com
Tue Nov 13 19:00:08 EST 2007


On Nov 13, 2007 5:17 PM, Pat Maddox <pergesu at gmail.com> wrote:
> On Nov 13, 2007 11:51 AM, David Chelimsky <dchelimsky at gmail.com> wrote:

<snip/>

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

I won't speak for all, or say what one should use. But what I do is I
change things one step at a time with autotest running in the
background. When autotest tells me something failed, I look at it.
When it tells me nothing failed and I expected something to, I look at
that.

Whether or not you have tool support, refactoring is its own world of
study - taking steps that move you in the right direction and keep the
bar green as much as possible.

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

Exactly

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

Actually, if I change something and it causes an example to fail, that
suggests to me that the examples ARE a good safety net! Just as in the
TDD cycle, the failures actually give you confidence that you're
touching the code you think you're touching.

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

You may just have to will it away. I find that this does not slow me
down. I'm slower on a step by step basis than I am with powerful
tools, but since I can solve the same problems with so much less code
in Ruby, it sort of balances itself out.

<snip/>

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

Without even batting an eye!

The scenario is going to reflect how things look from the outside. The
example is going to be targeted right at the part of the system that
is responsible for producing the correct error message.

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

This used to bother me too, but that was a long time ago. The thing is
that you want the examples to be comprehensive so you can refactor.
You also want the stories to be comprehensive, so you know what the
system does. And so you can refactor ;)

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

Anybody got any ideas?

<snip/>

Cheers,
David


More information about the rspec-users mailing list