Wednesday, December 7, 2011

10 Reasons to Avoid Test Driven Development

Test Driven Development (TDD), and all of its derivatives (BDD, ATDD) are, in my opinion great methods to drive a team’s development efforts, and raise the quality of the product. But TDD is not a silver bullet. It doesn’t fit every project. The following post lists the top ten reasons not to write automated tests for your code.

If one or more of these conditions apply to you, you should consider forgoing TDD, and in fact any agile techniques, as they will be a waste of effort:

10. There is no client

Sometimes you are developing a product that will not be used by anyone. In this case, any effort expended on raising the quality is a complete waste. Nobody will care.

9. The client is an avid tester

Some people love nothing more than to beta-test new software. The joy of finding new bugs and trying to figure out what went wrong is what they live for. Others are scientists at heart, and love trying to go over stack traces, in order to reverse-engineer the code. If your client happens to be one of those, then writing automated tests will take all the fun out of using your software. Don’t do it!

8. The project is short, simple and straight-forward

If your team can complete the project in a short period of time (no more than a few weeks), and will never, ever have to reopen it for maintenance, then the benefits of maintainability, reusability and extensibility will be lost on you. Spending time and effort on these values is wasteful.

7. Your architecture is perfect

If there is no way to improve your architecture, then there is no need for it to be extensible. TDD, by the nature of its incremental development flow, forces the architecture to be extensible, simply by making you extend it as you go, and this, like lipstick on a pig, is something you just don’t need.

6. Your documentation is perfect

You never miss an API, and any change you make to your software gets documented instantaneously. The tests you create with TDD serve as a form of documentation, an example of how to use the API. Properly named and written tests actually explain the context of the test, so it is easy to find the test that shows you what you need to understand. Your documentation is so complete, that writing tests are a clear violation of the DRY principle, so you should clearly avoid tests.

5. Your team never changes and all members’ memories are perfect

The collective memory never forgets a single line of code it wrote, nor what the context was when writing it. You therefore, do not need the tests to remind you what the code does, why it does it, or how to use it. This also means that your team members never leave, nor are any new members recruited, because if this were to happen, you’d lose memories, or have members who don’t remember the code (having not been there when it was written). If this is the case, don’t bother with tests; they will just interfere with your incredible velocity.

4. “Done” means the code is checked in

Many teams have a definition of done (DoD) that means that the feature is “done” when it is in a state that the end user can receive and run (coded, tested, deployed, documented, etc.). Many others however, your team included, prefer a simpler and more easily achieved definition that accepts “checked in” as “done”. For you it is sufficient that the developer declared that he or she completed his part, and anything else is someone else’s responsibility. If you don’t need the code to be tested for the product owner / manager / user to accept it, then you are better served moving on to the next feature as soon as you can, instead of dragging on your relationship with this feature.

3. You’re paid to code, not test

Ignoring the fact that unit tests are code (sophistry), testing is what we have testers for. Perhaps your team's testers are fast enough that they can run tests on your code and give you feedback within mere moments, pinpointing the areas where you broke the code, so you can fix it while the changes are fresh in your mind, as well as a complete regression suite on the product, in case you broke something in a different component every night (they don’t mind working nights; they love the peaceful quiet). Good for you, cherish those testers, and make sure they have enough work so they won’t get bored and move on to a more challenging company.

2. Debugging doesn’t count, and testing takes too long

Like with any competitive company, your team must deliver on time, which means they must make estimates on the time it will take to deliver. Since your DoD doesn’t include testing, and you probably can’t guess how long it will take to debug the feature, what with all the cycling back and forth from development to QA, you estimate how long it will take to code it. If you want to meet your commitment, you can’t be adding a 20% overhead to your delivery time or you’ll miss the deadline. Worse, if you add 20% to your estimates, your manager might call you out on padding the estimates, which is his job. If that happens, who knows what might happen? Better play it safe.

1. It’s just a theory

Like Evolution (and Gravity), it’s just a theory. Even if all of the above reasons weren’t valid, nobody has ever successfully proven that this product could be completed faster and with better quality using new-age development methodologies like TDD. It’s just a matter of opinion.

Test yourself

Now, to test whether or not you should use test driven development, go over the above list. Count how many reasons apply to you. If you scored ten points, don’t use TDD. In fact, if you scored more than one (reason #8 might actually be legitimate), don’t write any code at all. Perhaps you’d be better served choosing a career that has fewer unknowns and moving parts. Perhaps paving roads?

55 comments:

Yeah. Same. I am a heretic with regards to unit tests. I think the religious nature with which people TALK about it is overblown and the reality almost always falls short. The further you get from critical shared code, the less the value the effort delivers (IMHO). This is context dependent, of course.

10 and 8 actually make sense to me. I started reading this thinking it actually was a list of times when unit testing is overblown. There are times where that is true, religion be damned.

Well, I agree with you on #8. #9 WAS considered a legitimate reason in the late 90's. Customers tend to be a lot more discriminate these days. #10 could be legitimate only for throw away code, or exploratory code. You just have to understand that the code isn't production grade.

The only valid point is #8, the rest are NO excuses not to do unit testing. #6: Documents lie on you; I'm not referring to Uncle Bob, but to personal experience. #1: see testing and complexity: http://peripateticaxiom.blogspot.com/search/label/test-first%20complexity.etc. etc. Sorry, I consider this blog entry harmful

Maybe it was too early in the morning when I read the blog. Friends of mine laughed on me about my reply ;-)I was involved in the past in discussions where people seriously used the points above as excuses not to test. Therefore my rough first reaction.I would not add a disclaimer. It would really take the fun of your excellent and funny post. But maybe you can use a different color for the Test yourself section.Definitvely going to read your blog more often!

Without using sarcasm, there are some cases where TDD is useless. For instance when using languges that can be calidated from a formal or mathematical point of view, for instance Maude. As well as other paradigms like MDD, model driven development.

Isn't it every new technology is theory atleast practices if going via your opinion ? What motivates is to write better code which can sustain test of time and work on every possible scenario and TDD helps on doing that.

@Ricardo - I have to admit that I have no idea what "calidating" is (nor does dictionary.com, for that matter :) ), but if I wish to validate that a formula is written properly, and if I wish to give an example of how to use the formula, then [some kind of] TDD will really help.

Regardless, the post is titled "10 reasons to avoid..." not "THE ONLY 10 reasons..." :)

You are suggesting that TDD should be avoided in many cases but you're not offering an alternative. What is the alternative in the case where TDD cannot be adopted? (other than paving roads, of course)

you're suggesting that being stupid on the internet should be avoided, but you're not offering any alternatives. What is the alternative in the case where being clueless cannot be adopted (other than not reading the comments on your blog and still being a dick of course)?

@Wagner - Regarding the overheads, see point #2 (debugging doesn't count and testing takes too long). In my experience TDD doesn't add value only in simple and short term projects. See the rest of the points for the value TDD brings to the table. Remember that if writing the tests is difficult, it is an indicator that there's a flaw in the design! This means TDD helps improve your design.

The only thing I agree with is that you have to weigh whether TDD brings value to you or not. Don't cargo cult it.

@V. Narayan - while some of the values in my post apply to unit tests, as well as TDD, some of the advantages are gained only when writing the tests to drive the development, rather than just as a regression test suite.

You are aware that poking fun at an obviously wrong way of doing things is how the waterfall model was born, right? My problem with the above quote is that there is nothing logically incorrect about it. In fact, at face value, it is brilliant. Just like Winston W. Royce's mockery of the waterfall model someone may mistake it for genuine serious reasoning, and bring the fiery, cataclysmic end of modern software development practices, ushering us into a new technological dark age. YOU HAVE DOOMED US ALL!

Though I do appreciate the comparison to the late Winston Royce (and am aware of both his son's attempts at rectifying the situation), I do not fear the cataclysmic event you mentioned.

For one, in the 1970s, the DOD was the single largest customer of software. In those monolithic days, a 4-star general with brass-for-brains could (and did) send the industry into the dark ages. Today, there is no single such entity. Anyone who subscribes to outdated, inefficient methods of development will simply go the way of the dinosaur.

For another, call me naive, but I'm sad to say that I doubt that anybody dumb enough to think that this post is anything but sarcastic, will find his way towards reading this post.

I do hope that you at least got a good laugh out of the post; your comment had me rolling for more than a minute.

I got a great laugh out of this ... then I cried a little thinking about how many of the points actually describe attitudes of teams and team members I have worked with. Oh how I long to work with a team that takes every bit of your real message to heart. Thanks for the post.

But seriously, if you wish to work on a team that does TDD, start doing it yourself. Pick a project that is:1. Either green-field, or an existing one that you need to start a new module (or even just *can* start a new one), 2. Not likely to be contaminated by people who *don't* write tests.

Show others the virtues. Help others become as awesome as yourself.

Oh, and don't get discouraged if it doesn't work smoothly. I had to work rather hard to convince others that it is worth it. Usually takes a month or two until people notice that your life is easier and better.

I guess they simply refer to the fact that, so far, nobody has been able to explain what gravity is or where it comes from, just observe its effects. As for evolution, same thing goes for what its mechanisms are... is it really just successful randomness? or is it driven by something else? Ever heard of syntropy? http://www.syntropy.org/So yes, they are JUST theories, but I see your point in that they work out pretty well... which might not be the case for all computer scientists and TDD (what? what do you mean "flame-throwers ready, aim,..."?) :D

@Domenic, thanks for that. It's good to know that I gave you a good laugh. But don't be mad, read the comments - they're even funnier. There are some people here that didn't get the joke even *after* reading the comments... :)

As a road paver, I'm outraged that you'd suggest we use Waterfall methods. Regardless of what our clients may tell us about the condition of the ground, it's impossible to predict what you'll find once you start, so the tasks continue to change, messing up estimates and requiring agility.