TDD without the design
Date: 2008-10-01 00:32:20

http://weblogs.asp.net/rosherove/archive/2008/09/26/unit-testing-decoupled-from-design-adoption.aspx[Roy Osherove] and http://codebetter.com/blogs/ian_cooper/archive/2008/09/23/learning-and-crafstmanship.aspx[several] http://www.mockobjects.com/2008/09/tdd-killing-messenger.html[others] have posted recently about introducing TDD to the 'masses'

As I understand it Roy's idea is to separate the learning of TDD from the http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx[learning of good design principles] - good design principles in this case being the OOP principles described in Uncle Bob's http://www.amazon.co.uk/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=sr_1_3?ie=UTF8&s=books&qid=1222725859&sr=8-3[Agile Software Development Principles, Practices and Practices] or on the http://objectmentor.com/omSolutions/oops_what.html[Object Mentor website].

I am usually in favour of an approach that breaks a skill down into chunks so that it is easier to learn but in this case I feel that some of the big gains in coding in a TDD way is the decoupled design it encourages, which in my experience is more likely to follow good design principles.

One of Roy's suggestions is that popular mocking frameworks such as http://ayende.com/projects/rhino-mocks.aspx[Rhino Mocks], http://code.google.com/p/moq/[Moq] and http://www.nmock.org/[NMock] make it harder for people to adopt the TDD approach and that other mocking tools such as https://jmockit.dev.java.net/[JMockit] or http://www.typemock.com/[Typemock Isolator] would be more suitable.

When I first learnt how to TDD I didn't know about any mocking frameworks and while I could see some value in the approach, I was often writing 'unit tests' which connected to real resources therefore losing the quick feedback cycle which TDD encourages.

Ian Cooper believes that the most important step is starting http://codebetter.com/blogs/ian_cooper/archive/2008/09/23/learning-and-crafstmanship.aspx[to use TDD rather than doing it correctly] straight away:

____
The difficulty with the software community is that experienced practitioners can overwhelm newbies by flooding them with information on 'how to do it right'. The problem is that the most important step is not doing it right, but doing it at all.
____

This was the route that I inadvertently went and while it does provide an incremental approach to learning I feel that I would have seen the actual value in the TDD approach much earlier if I'd learnt http://www.mockobjects.com/2008/09/tdd-killing-messenger.html[TDD as a design tool], therefore meaning that I would have had to learn mocking at the same time.

While it may indeed make TDD more accessible, wouldn't it be better to have less people adopting it but that those who do adopt it really understand it and can help spread the message.

Instead of trying to reduce the learning curve, let's try and help people to conquer it more quickly.

I appreciate that not everyone who learns TDD has the environment or opportunity to execute it perfectly but at least by having all the information available to them they can make an informed choice on how they use it rather than the scenario which I could envisage happening where you eventually end up with two versions of the same concept - Test Driven Development & Design and plain old Test Driven Development.