[rspec-users] Do you still Write Tests First on code that is churning hard?

Matt Wynne matt at mattwynne.net
Fri Feb 19 07:21:36 EST 2010

On 19 Feb 2010, at 08:59, Erik Pukinskis wrote:

> Hello Specmeisters!
> I have a bit of a philosophical question for the TDD witches and
> wizards out there.  I'm working on some code that is really
> churning... It's doing complicated calculations, but the actual
> desired results are a moving target. The acceptable values, and even
> the structure of the software's output are changing constantly.  The
> internal architecture is changing rapidly, and I'm constantly throwing
> away methods I no longer need.
> This has resulted in me no longer writing specs on this part of my
> codebase.  They just become obsolete very very fast.  Changing the
> specs constantly feels like a pointless doubling of my effort.  Specs
> seem to help with debugging and verification that the software is
> performing as expected.  But I'm spending most of my time trying to
> figure out what I should be expecting.  I verify that things are
> working quickly and informally, because it's likely the definition of
> "working" will change before the week is up.
> Am I being stupid?  Is it really a pointless doubling, or am I
> creating more debugging time for myself than I'm saving without
> writing specs?  Should I be more religious about Test First?
> Thanks in advance for the insights,
> Erik

Here are some rules of thumb I would use:

If requirements are churning, I would try to use high-level acceptance  
tests (e.g. with Cucumber) to firm them up.

If I can't firm up my requirements, it's because we're still going  
though a discovery process - we don't understand what the problem is,  
let alone the solution - and that means it's too early to write any  
production code. I would happily write code without tests at this  
point, but I'm going to be loud and clear about the fact that the code  
I'm writing is a spike, and will have to be thrown away and re-written  
before we go live. This kind of code is much more valuable than you  
think - most of the value is in the learning that goes into your heads  
as you do it, rather than in the cobbled-together, un-tested code you  
write. Writing code like this can be fun, but never be tempted to  
check it in!

Once the requirements start to stabilise (but are still changing) I  
often go through a process where the design is still churning as I try  
to work out how I best want to solve the problem. At this point I  
would rely on those high-level acceptance tests to cover me and only  
write specs for parts of the design as it started to stabilise.

The thing you have to remember is the point of TDD/BDD is to surface  
uncertainly and misunderstanding early. Once you get past the  
discovery stage, having the discipline to write tests first will  
reduce churn, because you ask more questions (and make more decisions)  
before you actually sit down and write code. If you don't have enough  
information to make those decisions though, don't be afraid or ashamed  
to write a spike, but make sure everyone on your team understands the  
distinction between that and production code.


+447974 430184

More information about the rspec-users mailing list