[LRUG] TDD (was: Ruby Contracting)

[Chris Parsons]

Hi Ellie,

An excellent, well reasoned response. Worthy of a blog post!

On 19 Feb 2009, at 13:16, Eleanor McHugh wrote:

> If you build a test suite of 6 KSLOC for a shrink-wrap you'll have  
> 20 defects which may not seem like many until you realise that  
> mainstream TDD lacks tools for identifying those defects. It's not  
> self-testing. Now a defect isn't necessarily a bug in the 'this line  
> of code is incorrect' sense although if they were it would make our  
> lives much easier. Unfortunately it's often the result of  
> misunderstood or missing requirements and that's beyond the  
> competence of a machine to identify.

Very true. Problems with our projects usually boil down to problems  
with requirements. We work hard to minimise those as much as possible,  
that's what I and the other project lead here spend a lot of our time  
doing.

> As a result programmers are in general the worst people in the world  
> to be testing code - at least their own code - as their theoretical  
> understanding of what needs to be done can and will interfere with  
> the impartiality of those tests. There are ways around that such as  
> having developers write tests for one set of requirements and then  
> write code to fulfil the tests written by one of their colleagues  
> but that's only practical if they're either working in a relatively  
> large team (like a ThoughtWorks pod) or a very disciplined  
> environment.

I agree with code reviews for improvement in both the code and the  
coder. Having your code reviewed by a machine just doesn't cut it, you  
need a human to show you how to improve. Testing doesn't make you a  
better coder, it just makes you a less stressed coder. Whether that's  
a good or bad thing depends on the ability of the coder :)

You do lose the following distinct advantages of testing though:

* The ability to perform easy regressions. Most of our projects live  
in the 'client doesn't quite know what they want' space. Figuring out  
the requirements they need is key, along with constantly refactoring  
and improving the tests.
* There is an interplay between tests and code so more bugs are caught  
in both code and in tests than normal.
* Testing does however point you in the direction of design smells in  
your code; this doesn't make you better, but it catches you being  
stupid, and forces you to design good code (asking a human for help if  
you need to).
* As Vahagn just mentioned, tests are great documentation (although  
only if written well).

Another important point: Thanks to RSpec/Cucumber/Ruby, testing  
happens to be easy for us. If the constraints of your environment are  
such that testing is more difficult, then I can understand the balance  
being tipped in the favour of a manual review.

> A couple of years ago there was a lot of passion in Agile and [B| 
> T]DD is one of the fruits of that. As usual early adopters received  
> big initial gains compared to larger players and so everyone has  
> rushed to join the bandwagon. These methodologies in the hands of  
> someone who loves and nurtures them will work well but that tells us  
> more about the developer than about the methodology.

Couldn't agree more. I hire based on developer ethos/talent more than  
anything else.

Thanks
Chris

--
Chris Parsons
Managing Director
Eden Development (UK) Ltd
www.edendevelopment.co.uk
Twitter: @chrismdp