[TIP] Column questions.

Laura Creighton lac at openend.se
Thu Jul 24 01:37:30 PDT 2008

In a message of Wed, 23 Jul 2008 23:17:42 +0200, Andrew Dalke writes:
>Laura Creighton:
>> Should I really write my tests first?  Why?
>   Does writing the tests first discourage API modification?

    Not for me, instead it makes it a lot easier for me to modify
    my API.  But then I am a 'design your API last, or at least
    fairly close to the end of the process' sort of person.

>I've noticed when I try to write tests-first it's very
>annoying because after I have an idea of how the system
>should hang together, I rewrite the API to fit that more
>appropriately, which means I spend time rewriting my tests.
>I tend to iterate API changes, which means I spend a lot
>of time updating test code.  I end up not wanting to make
>changes because there's already code which depends on
>the API.
>The agile approach seems to say "spike the solution then
>throw it away and rewrite based on the knowledge." But
>by the time I figure out a good API it's easier to fill
>in the details and add the tests then than it is to start
>from scratch.

Only some agile approaches advocate the 'throw the spike away'
approach.  I think this rule is for beginners, and for people
who don't want to write their spikes test-first.  If you write
your spike test first, then I don't see any difference between
merging those two code bases and merging any two code bases --
the sort of normal, refactoring job that happens a lot.

So this is interesting to me, because the times when I find
myself rewriting the tests so fequently that it is annoying
pretty much always mean that I've screwed up by prematurely
creating a too rigid API in the first place.  (Which may have
been unavoidable -- as when you aren't writing code from
scratch but refactoring two different chunks of code that
were written entirely independently of each other but which
you have now decided should share an API).

But in those cases I haven't found that it is writing the tests first
that cases the frustration.  It's working with people who absolutely
believe that in all cases you have to get all the old tests working
before you can write new code.  While moving from one API to another I
always go through a stage where I have to skip a whole lot of tests,
and I don't go back to fix them until either I have refactored enough
that the new API is in place, or I have made enough changes that I am
afraid of making any more without first getting all the tests to pass.
But that doesn't mean I am not writing tests first to test the moving
from one API to some sort of scaffolding and then moving from there to
either a different one or to the destination API.  It sounds to me
as if your frustration may be of the same sort -- it's not the
updating of your tests which are bothering you, but the updating
of them to something which is only doing to be thrown away in
another half hour or 45 minutes or 3 days that is annoying you.

Or am I reading my own experience into this, and not seeing 
what you are writing?


>				Andrew
>				dalke at dalkescientific.com
>testing-in-python mailing list
>testing-in-python at lists.idyll.org

More information about the testing-in-python mailing list