Code correctness, and testing strategies

[Patrick Mullen]

I can see both sides of this argument, and I think TDD is great in some
cases and not so great in others.  I have used it before, but don't use it
often, as the programs I write are very difficult to automatically test.
(Games, which many of the bugs have to do with whether an optimization
produces a visual artifact or not etc.  Not possible to test that!)

As far as time spent testing, it obviously various per project, person, and
methodology.  But I think you have some misconceptions about coding time.
With TDD, you cannot measure test writing and code separately.  Here's why.

When you write code and then write a test for it, you spend a lot of time
thinking about how the code is going to look while you are writing the
code.  You plan what the code is going to look like, what arguments are
going to be passed to a function, how the code might be used by other code,
etc.  This is thinking time, with no code written.  This is also interleaved
with the actual time spent writing the code.  (You are thinking of the plan
while you are typing the actual code).  Then you will likely do some sort of
debugging at least, if not writing a test.  This doesn't take much thought
as you have already front loaded the thought.  "Well I should print here to
make sure this line is correct."

>From a TDD perspective, most of the actual time is fairly the same, just
shifted around.  The thought process that I mentioned, of how code is going
to be used or how it fits the system, instead of being hinged on the code,
is now hinged on writing the test.  This makes the thought process more
formal than in the other methodology.  Instead of thinking of one thing (how
a function may be used) while doing something else (writing an if statement
within some logic), you are actually writing code based on the system
instead of the internal logic.  Then, you write some code that makes it
work.  In many cases, (and in my experience) the actual code is easier to
write in TDD, because it is more focused and directed.  I am not writing one
thing and keeping in mind other things.  You think, plan, and then write to
spec.  It is most certainly a more formal process, and can be hard to get
used to.

And it doesn't work in all situations of course.

But timewise it seems like all the processes are the same.  Without tdd, you
might, instead of writing a test per say, still spend that time writing a
doc string, or just looking at where a function will be used to see what the
code should look like etc.  I think though that test-first streamlines
things a bit.  By itself I don't think it makes the process faster, and that
front work of writing the tests can definitely feel slower.  Further on is
where you have the most benefit of having tests.  And with practice you can
get faster at it too.

Most programmers have their own methodology that they have used for a while,
so they are fast at it.  Any change in that is going to be extremely
sluggish until you are used to it.  You should try TDD at least once for a
small or medium project and go all the way through with it just to get a
feel for it.  If you can afford to of course :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080524/14fe34ad/attachment-0001.html>