I came across this blog post about when not to follow TDD. The author in this post breaks development down into two modes. Experimentation and Focused mode. In Experimentation mode it’s ok to not do TDD. While I generally agree that TDD doesn’t make sense when you don’t know what your doing I think we have to be careful to limit just how long this Experimentation phase can go on for. So here’s a couple caveats about not doing TDD.
- Misconception #1. If we stop writing code test first, just for a little bit, we might be able to meet this
ridiculouslyshort deadline. – It’s natural to assume that cutting corners and not following your process for a short time will result in faster development. You can write code faster without writing tests first, but the result will be buggy, and hard to maintain. Add to that several developers writing buggy, poorly designed, and hard to maintain “cowboy” code and your going to start having development efficiency problems quick. Especially in the embedded domain where electronic signals can be hard to access. - Misconception #2 If we fail to meet the deadline quoted above the sun will never rise and our customer will walk away. – I understand this impulse to please the customer at any cost. Sometimes in a sales setting this is the only mindset of the day. We have to be careful to manage the expectations of a customer in order to not end up in situations like this. In my experience this can be hard for managers to understand or even acknowledge. (There’s 24 hours in a day and 48 hours in Saturday and Sunday!) This is why it’s so important for TDD or any process to be implemented and defended from the top down. If a deadline looks unattainable it’s better to find ways to limit the scope of the deliverable or negotiate a more realistic deadline.
- Misconception #3 If we stop doing TDD for a little while we can always pick it back up again later. – What happens here is that your quality of code takes a nose dive. You have no guarantee that you will meet said deadline. And, once TDD begins again you will have a backlog of untested code that still needs to be tested and possibly rewritten. This is just setting yourself up for another unrealistic deadline
Cutting out TDD is no guarantee that you will meet your deadline. You could end up missing the first deadline, and the next, when, if you would have followed the process, you could have at least made the second. I think the right guideline for suspending TDD is to stick to hours not days. It’s alright to do a spike test and figure out how to get that widget to spit bits, but you have to write tests and re-factor in your next step.
3 Comments
I think Misconception #1 can be perfectly valid and not recognizing that is it’s own misconception. I had this experience recently when I needed to fix a bug by changing a “greater than” to a “greater than or equal to” that was part of a report. Unfortunately the code I work with is the result of nearly 8 years of many contractors and developers who seem to like huge classes, globals, and complex logic in the gui. So to write a unit test before making my change, I had to extract the report logic from the web page and nested web controls so I could verify it. It took over four hours to write a unit test to make a one character change that I already know to make. And as careful as I was, I may have introduced new bugs during my refactoring.
How long should it take to write a test before making a small change? A few minutes? A few hours? A few days (3 days is the longest I’ve spent)? Would you say that taking a few weeks to write a unit test is perfectly fine?
Trystan,
The point of following TDD is to never end up in a situation like you described. Unfortunately we do sometimes end up dealing with legacy or supplied code that isn’t testable. This is particularly true in the embedded world. I feel your pain because right now I’m working on a similar project (though not quite as bad). Sometimes the ROI on starting unit testing won’t be there. We have to be practical about it. On the other hand, I’m sceptical when people say that they just have to make one last change to a piece of code and it will never be touched again. There’s last changes and then there’s last changes and since I don’t like to make predictions, especially about the future (-Yogi Berra), it’s tough to know what type of last change it is.
I think you did the right thing by refactoring. Think of it as repaying technical debt. Not fun, but it had to be done and next time you have to make a change you’ll be far better off. Would I spend 3 days or 3 weeks refactoring? I guess it depends on what my options are. I wouldn’t say: “yes no matter what”.
@nick, That’s a perfectly well reasoned response, exactly what I like about this blog. Many TDD advocates love to point out the possible benefits of TDD but ignore or downplay the costs and seem unaware that sometimes writing a test can take more time, knowledge, or skill than available. It’s the “yes no matter what” crowd that bother me: it’s not always as simple as saying that anyone who doesn’t use TDD or BDD is misguided, incompetent, or doesn’t care.
One Trackback
[...] need to brush up on their testing and TDD knowledge:)Testing articles and papers at Atomic ObjectWhen is it ok to not TDD?Wikipedia entry on TDDKent Beck’s TDD By ExampleYou might also like:‘Embedded [...]