[LRUG] TDD (was: Ruby Contracting)

[James Adam]

On 19 Feb 2009, at 10:22, Tom Stuart wrote:

> On 19 Feb 2009, at 10:16, Chris Parsons wrote:
>> Writing good tests is harder than most people think, and there's no  
>> substitute for manual tests.
>
> Without taking sides, what surprises me is how few people say  
> anything about just how hard it is to write useful, robust,  
> intelligible, non-brittle tests (especially for e.g. Rails  
> applications) and how much time it takes to create and maintain  
> them. Common wisdom is that this investment of time and effort more  
> than pays off in quality and stability but, well, is that appealing  
> idea necessarily always true? Is there really nobody in the world  
> who actually wastes time writing tests?


I think it would be hard to argue that all tests were actually useful,  
and it's generally a good thing to ask when writing a test - how much  
value is this test adding?

A mistake that I made all-too-often when I was being schooled in TDD  
was writing too many tests around implementation-specific classes, and  
not enough that actually described the overall behaviour I wanted -  
tests that describe the actual value of the feature I'm working on,  
rather than those that crystalise the particular architecture-du-jour.  
These days, I always try and start by writing tests at the highest  
possible level to describe the behaviour I want, and then as the  
internal APIs start to coalesce I can start to look more that the  
'unit' tests.

It's possible to spend a lot of time testing every aspect of an  
application at every level (individual classes and various levels of  
integration), but I'd argue that not all of those tests are adding the  
same amount of value. Perhaps a "good" TDD programmer can spot which  
kinds of tests are the most valuable in a particular situation?

Speaking of value - the real value of automated testing isn't  
immediately realised; the payoff comes months later when you or  
someone else needs to make a change but be relatively confident that  
everything still works. Sure, you can use them to verify the method  
you literally just wrote, but that's a trivial benefit for a seasoned  
programmer. It's hugely tempting, particularly for those of us who've  
been "programming forever", to feel like writing tests just slows us  
down, and that our experience is enough to ensure that the code  
matches our intention. This is arrogant folly for two reasons:

1) It assumes that our intention matches the customers. Codifying  
behaviour in high-level tests is a great way of making sure that  
everyone has the same expectations, because good tests rarely talk  
about the nitty-gritty nature of computing, but things like "If a user  
signs up, they get an email with a confirmation link".

2) It assumes that we, the programmer, will always be able to keep the  
entire system in our heads any time we need to work on the code.

Writing good tests is hard, but without some form of regular testing,  
there's simply no way to keep up velocity on a project.

James