No More Buts

“Doesn’t unit testing add code effort?”

If I had a dollar for every time I was asked that question…. People use this as an excuse not to begin writing tests.

I used to say: “You know, industry standards say it’s 20 percent more, but it’s worth it”.

Not anymore. No more buts.

Unit testing and TDD helps you release better products quickly. Period.

“But we’ll be writing more code!”

Maybe. Or maybe you’ll write less code, because you’ll have a better design. And then you’ll spend less time on hacking fixes.

“But we’ll spend more time on writing tests!”

Yes, because you’re not writing tests now. That’s inevitable. In the meantime, you’ll have less bugs. Which means you’ll be debugging a lot less. And that means you’ll finish features quickly, not five times in the next 3 months. You know – “it’s done except for those bugs the testers found”.

“But now we’ll spend time fixing tests!”

Yes, you will. While you learn how to write tests, you’ll stumble. And then you’ll learn how to write smart tests, that don’t break easily. And it’s still better than debugging for days until you reproduce a bug, and debugging more to prove it’s fixed.

Industry standards talk about programmers writing 10 lines of code a day. Good developers remove this excess per day, but let’s stick to the “standards” for a minute. You mean to tell me that 2 extra lines a day will make you work a lot more?

No more excuses, no more buts.

Start writing tests today.

One comment

  1. craig bowes August 2, 2012 at 12:01 am

    I’ll play devils advocate here.

    I DO write tests, so i’m not one of these developers who has never done TDD or BDD and doesn’t know what he’s talking about.  I’m sure I have some room for improvement in writing small, not easily breakable tests, but i’m no newbie either.  I love having test coverage and I love having the freedom to refactor and know what i broke and how to fix it.  

    There are definitely projects that can benefit from writing tests, and then there are projects that probably won’t.  First off, you have to ask yourself some hard questions.  how many bugs are you dealing with for every 10 or 100 lines of code you write?  Do you product a lot of bugs now?  Second, how much is the project likely to change?  Is it a small, 3 month project, or a bigger project that could last 6 months or more, or even several years, with various changes over time?  Because where tests really pay off is in large projects that change over time.  If your aren’t changing the codebase a lot, then there’s little reason to refactor and little chance you’ll create bugs when something changes, because, well, you’re not changing much.  Another question.  Do you have multiple developers working on the same project, or just one?  If multiple, there is more of a chance that developer A can break code written by developer B.  In that case, writing tests helps not only the design, but acts as a warning system if someone breaks something because they don’t know the whole system.

    So, rather than be ideological about it, I try to be practical on whether to write tests.  What is the size, scope and duration of the project, how much bugs do your developers produce, how many developers do you have working on it and what is its complexity?  Bigger projects with bigger scopes, more developers, more potential for bugs and more complexity all point to more of a need to write tests.  Smaller projects that don’t have these properties, well, chances are with good developers you can get away without tests.  
    Its all about return on investment.  The initial investment of writing tests has to pay off in the ability to change the code or refactor later or to avoid the debugger.  If you don’t have a need to refactor or change the features and you’re not really writing that many bugs, then where is the payoff?   You may say the payoff is in a better design, but better design only helps if you’re changing code, making it more readable for the next guy.  Your users don’t care what the code looks like.  

Leave a reply

Required fields are marked (*)