- Development has slowed to a crawl, because it’s difficult to add features.
- New bugs are introduced into the system when old bugs are fixed.
- You’re worn down by that nagging feeling that something, somewhere in your software is broken.
- Your QA involves hours upon hours of manual testing.
- It’s expensive to add new features (see #2)
Bugs keep cropping up in your software.
And the list goes on.
Test driven development.
The primary reason for doing test driven development is that it allows us to fearlessly refactor our code.
If we can fearlessly refactor our code, we can clean it.
If we can clean it, we can make it easier to change.
If we can make it easier to change, we can move quickly.
For the first part of my career I didn’t use TDD, and I ran into all the problems listed above, and some. I eventually got fed up, and made the switch.
The difference was stark.
No longer did I have to hold the program in my mind, the various connections, which objects talked to each other, state, and so on. I could off load that cognitive load onto the computer. The computer would let me know if I’d broken something.
Before I cared about working code. It worked - even if it was badly written - so why change it? Now, I can take a chainsaw to my code. I don’t care if it breaks, because I have a test that will guide me back to the desired outcome.
I’m not saying that TDD is a fix-all solution, but it is a fix-nearly-all solution, and you should use it.
Which brings me to the purpose of this site, to teach people about TDD, why it’s awesome, and how to implement it.
I have a wife, a son, two cats (who I refer to as the corporate fat cats), a dog (yellow husky), and a Ninja blender (the best blender ever devised by the human mind).
If you’d like to contact me, you can email me at michaelandrewspangler at gmail dot com, or find me on twitter.