Speed Bumps
The last project I was on, I attempted to be very disciplined and do test-driven development all the time. This didn’t also work out. Far too often I found myself writing code for which I hadn’t written tests first for. I would have to stop myself and write a test first. Similar to driving, the tests acted as speed bumps preventing me from going to fast.
Most of the time, writing tests was fine. They forced me to think about what I was doing. Instead of creating single, long methods that did more then one thing, the tests forced me to create small, single purpose methods. This resulted in cleaner code that was easier to test and easier to work with. And it also resulted in a much clearer understanding of the solution that I creating.
However, there were times when I knew exactly what I wanted to code and how to code it. This is where the speed bumps came in. Instead of just forging ahead and programming, I had to stop and create tests. And I must admit, far to often, I coded my solution first and created tests after. And far too often, I had to recode what I had done because it wasn’t testable. So the speed bumps, although frustrating at times, in the end proved to be the better way to code.
Yep … agree … the point is that it is a misconception to think you are going anywhere without testing first … so nowadays I when I feel like “I know exactly what I want to code and how to code it” that implies its test driven code …