It’s been a busy week that started somewhere three months ago and I’ve missed most of the whole “TDD is dead” argument.
If you’re interested in unit testing and TDD (and you should be) – this is a great opportunity to listen to great minds and learn what they think of the subject – I know I learnt a lot and plan to continue watching till the end (there’s .
Although I only got as far as the 2nd part– I can see a pattern emerging – it seems that every argument for or against TDD is actually about unit testing.
It seems that the discussion is not about “why TDD is good/bad” but a discussion about whether or not use unit tests (use!), the unnecessary layers of abstraction they might introduce (the dreaded design for testability) and how people completely miss the point by tying themselves to implementation by over mocking their application.
A quick search in the internet showed me why at least one of the participants think so:
DHH has a good point – obviously how you write unit tests effects directly the way you practice TDD.
But there’s more to TDD than just writing unit tests just like there’s more to software development than writing code. I always argue that the unit tests are a byproduct of TDD and not the other way around – we use unit test to drive our code design, and at the end of the process we’re left with a pretty decent test coverage that can prevent regression but we’re also left with a very specific design – which is the objective of the whole process.
Knowing how to write good unit tests is crucial in order for TDD to succeed – but you also need to have good coding practices, know how to refactor your code and a thing or two on software design in order to be successful.
Because TDD is not about writing unit tests – it’s about design. The tests are there to help with that and theoretically can be deleted as soon as you’re done writing your code – although I’m yet to find someone who would give up the benefit of having the unit tests.
I hope that the next 3 parts of the hangout would concentrate on TDD as a design methodology and leave the unit testing discussion behind.