Roy Osherove and several 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 learning of good design principles - good design principles in this case being the OOP principles described in Uncle Bob’s Agile Software Development Principles, Practices and Practices or on the 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 Rhino Mocks, Moq and NMock make it harder for people to adopt the TDD approach and that other mocking tools such as JMockit or 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 to use TDD rather than doing it correctly straight away:

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 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.