TDD, Unit Test or nothing?

I’ve been thinking about unit testing recently prompted by a talk at .Net Developer Network, a presentation recorded at Agile 2009 and a blog post by Joel Spolsky.

Now I try hard to remain open minded about different methodologies but that doesn’t mean I won’t ask questions about them and often find that the way that the people involved who are ‘championing’ the methodology answer those questions effect my attitude towards it.

In the recent talk at .Net Developer Network given by Stephen Oakman and Ronnie Barker of the Agile workshop  they focused on using TDD, in this case Test Driven Design, to create an application but being very disciplined (strict?) and following TDD to the letter:

• write test
• test fails
• write just enough code to pass test or refactor existing code.
• test passes
• check in to source control.
• Repeat

Now I have no objection to that know I haven’t been doing pure TDD which has prompted me to look into it further – a good thing.

What did occur to me though is the amount of time it takes to create the code although Steve & Ronnie say you get faster as you go along I felt myself wanting to take a bigger step forward than they were doing i.e. write a bit more actual code rather than lots of small tests. 

My issue, if you like, is that the process seemed to take a very long time and although it would have been thoroughly tested it will still need to have the tester go through the code, remember “unit tests prove the correctness of the code, testing proves correctness of the functionality” but I also know what my manager would say with the increased time to finish any piece of work.

The next day Joel Spolsky blogged about ‘The Duct Tape Programmer’ which seemed to be the complete opposite of what Steve and Ronnie talked about and I can understand the desire to simply ‘code it’.  I have also recently watched a presentation by J B Rainsberger called ‘Integration tests are a scam’ which did highlight the fallacy of some of the testing we as developers do.

I think that as developers we need to use our own judgement as to what we test and whether the investment in writing tests will pay off for example should you bother writing tests for an application that consists of a single call to the database to record minimum information and has a half life of about a month?

I fully believe in unit testing this doesn’t mean pure TDD but does mean writing tests, if you can utilise the VS ‘Create unit test’ functionality’ or if you can use a tool like PEX to generate edge cases and the other tests that would take a long time to create then use it and save yourself time and be happy that your code is tested.