[rspec-users] How to spec code with multiple (interacting) paths

David Chelimsky dchelimsky at gmail.com
Tue Feb 20 11:57:40 EST 2007

On 2/20/07, Jerry West <jerry.west at ntlworld.com> wrote:
> I doubt there is an ideal solution.  You might try to encapsulate the
> different behaviours in different classes (each spec'd separately).
> Where there are true alternatives, you could use SimpleDelegator to
> delegate to the appropriate class depending on your flag.  No less work
> but conceptually cleaner perhaps.
> Alternatively (better?) work to eliminate the flag. especially if it's a
> do / don't do choice.  If you don't need to do something, don't call the
> code.  Push the decision and hence the spec up a level.  The calling
> routine should not do anything if the flag is false.  This is the
> boundary case of delegation: there's no need to spec a class that
> doesn't do anything.
> Lastly, you might think of the spec from the point of view of the flag,
> not the object.  In other words, the customer wants something to happen
> under these circumstances and these other things to happen under those
> circumstances.  Write your code to match these specs and refactor the
> commonality into shared routines, using your specs to increase your
> confidence that you haven't introduced (too many!) bugs.  BTW, it's
> almost always possible to change code somewhere and still pass the spec
> - the trick is to write the spec before you change the code!

AND watch it fail. That is key!!!!!! The cycle (from TDD) is:

1. write a failing spec
2. make it pass with the simplest thing that could possibly work
3. refactor to eliminate duplication

Note that "duplication" here refers to duplication either in the
subject code or between the spec and the subject code. IMO, some
duplication is OK in specs.

As to Ashley's initial post, I agree with Jerry in that the first
thing I'd look to do is see how I could break up some of these
responsibilities. FWIW, whenever I find that something is hard to
spec/test, I look at that as a design problem. But sometimes the
simplest thing that could possibly work isn't all that simple and you
have to find trade-offs between complexity in the system and
complexity in the specs.

Not too helpful, I realize.


> BDD isn't
> a guarantee of correctness, merely an aid to design and coding that
> increases your confidence that your code will do (only) what is required.
> Best wishes,
>   Jerry
> > I can't find an ideal solution to this situation, but unfortunately
> > it crops up quite often for me.  Has anyone got any experiences or
> > opinions that will help?
> >
> > Cheers
> > Ashley
> > _______________________________________________
> > 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

More information about the rspec-users mailing list