I am part of a developer team that works with many other teams to maintain and improve an application that has been in use for at least 15 years. When it was first built and designed, TDD was unheard of.

The application is fairly stable, and we rarely encounter a show stopping bug, but we do average about one or two bugs a week that seriously reduces the quality of service. These bugs take forever to find and fix, largely because of finger pointing, and the only testing we have is interface testing. Because there is a lot of wasted time hunting down where the bug is before it can be fixed, me and another developer plan to propose Test Driven Development. There is a new overhaul coming soon, and we would like to see near complete unit testing done on the new modules, we also plan to suggest building test units for any code we have to alter that is legacy (i.e., bug fix or feature implementation), but not to spend time developing test cases for code that hasn't caused problems.

To me, this seems reasonable. This month we had a bug that took over two weeks to fix, but could have been identified before deployed if unit testing had been done. But to our managers it just looks like they're going to spend more money.

How do I convince our clients that they want to spend the money for unit testing and test driven development? Are there any studies that show the ROI of unit testing?


3 Answers 3


Direct incorporation of full-blown TDD into a legacy code, maintenance project is a very hard sell. An approach I've seen work very well is this. For each bug that comes in, create an automated non-unit test that demonstrates the bug. By "non-unit", I mean something that can touch many parts of the system, hit database and filesystem, etc. - but by "automated" I mean runs without human interaction. This is the kind of test that you will want in your regression suite in any event. Writing it accomplishes a lot of things: it makes you make the code testable, even if at that very coarse level, and it exposes you to the constellation of code that might have something to do with the bug, so it educates and informs you about very specifically relevant material.

But that's not the end of it. Once this test is running, and running red (demonstrating the error in the code), take the time to figure out what's wrong (you have to do this, in any event). But don't fix it yet. Once you've isolated what you think is the problem - write a unit test that demonstrates that problem. Now you've got something you can work with (and, not incidentally, you may have had to refactor a tad more toward still greater testability). Fix the bug. Watch the unit test pass. Maybe flesh it out with some edge cases; get that one unit - the one that just cost you two weeks' of time - solid and clean and well-tested. Now run the regression test and watch it pass (of course, if it doesn't, you've got some more research and unit-level work to do - iterate until it, too, is passing). Check it all in. What have you got? Regression tests for previously failing code. Unit tests for previously failing code. Working code that was failing. Better designed code, because now it's more testable than it was. Better confidence in your code base, a better understanding of one of the nastier parts of your code.

It's not "pure" TDD. But it demonstrates results, quickly, and improves the quality of your code over time. The results will help you get management buy-in.

  • Great suggestion, but I think the OP is looking for a more convincing argument that justifies the extra time required to implement this kind of approach.
    – Bernard
    Commented Jul 7, 2011 at 16:48
  • 1
    Maybe I need to reword it, then. What I tried to express was that most of the effort described is necessary anyway - the extra time is very modest, for significant benefits. I'm sorry if that wasn't clear. Commented Jul 7, 2011 at 16:50
  • It's clear to me as a developer, but I know that management usually needs a very convincing argument (i.e. justifying the expense).
    – Bernard
    Commented Jul 7, 2011 at 16:52
  • That's what I suggested in my second paragraph in the question. We'd write TDD for "new code" and write test cases for any legacy code we altered either by bugfix or feature request.
    – Malfist
    Commented Jul 7, 2011 at 17:13

At my company, I just went with the "only a grunt" method from JoelOnSoftware and began writing unit tests whenever I normally would have simply hacked together some sort of throw away console application. I started getting things done a lot faster with more stable releases, and got noticed for it. When asked what I was doing, I explained that I had begun using TDD and writing unit tests whenever I modified old code or wrote any new code. My fellow developers started to get curious and began using integrated unit tests themselves. I don't think there is a good argument out there for writing tests for working legacy code, but if you can make the case that writing automated tests is faster and more convenient than writing console hack spaghetti, then smart developers will follow along. The other benefits that result in higher quality software will be there too, but the key to getting developer sign on is showing that it makes their lives easier. As far as business sign on, the fact that it will result in better software and probably take less time to ship than before should be more than enough to convince them.


First off, your attitude and sense of sincerity for quality value add to customer's money should be appreciated. And here are my thoughts on how you can convince your manager and client:

  • Collect the metrics of bugs that you were fixing say for the last 6 months and the minimum, average and maximum time that it took for you to fix a bug.
  • For all the bugs that you have fixed or have context about, try writing unit tests covering those areas.
  • For the bugs that you are working on and the ones that you'll be working on, try writing unit tests around those areas even before you make any changes. Then write code to figure out the cause and fix it. See if it breaks any of your existing test case. If yes, then explain and help your peers understand the importance of Unit Tests.
  • Once all the developers understand the importance of Unit Tests, ask them to continue doing what you have been doing for so many days/weeks.
  • As time moves, the teams productivity should improve to the extent that both your manager and customers would be surprised at the rate of improvement in productivity and the quality of code. Its a little time consuming, but worth trying.

There is another way, and it is to try joining your manager in attending Agile Conferences that happen around. It certainly should be worth attending.

If you think nothing works, then move on...join the place that fits you. Candidly, this is what I did. When everything failed, I moved on ;)

And know what Unit tests after writing the code is not really TDD, but then that can always be the first step. It fits so well here atleast.

Wish you good luck and success!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.