When I have to implement a new feature or fix a bug, I usually try to recreate the situation with a test. I sometime spend around 3 hours coming up with fixtures and writing the test. The actual feature implementation or bug fixing takes less than 1 hour.

Does anyone else out there spend at least 3 times longer to write a test compared to actually implementing a feature or fixing a bug? What's the acceptable ratio of time spent writing test to writing code?

  • 2
    Think of it this way: Would fixing the bug take less than an hour if you didn't have a test to confirm it existed, much less was fixed? – Michael K Jun 16 '11 at 14:29
  • 2
    Answer to the question title: As long as it takes. – Marcelo Jun 16 '11 at 14:54
  • 3
    I think slavish obedience to TDD principles regardless of cost or business value is always the right response. – Jeremy Jun 16 '11 at 15:40
  • How do you handle the case where your manager wants you to put the fix live ASAP and can't wait for an extra day to fully test the implementation? – Thierry Lam Jun 16 '11 at 15:52
  • 2
    Usually I explain the cost of not doing the test. That is, I can ship the fix now, but if we don't write the test, we'll have to do the whole thing over again later. Some times they're OK with that future cost, but usually we write the tests. – Christopher Bibbs Jun 16 '11 at 16:20

It varies on the complexity of the bug or feature. I recall one project that once had a 1.5 week development tiem estimate... and a 3 month testing estimate. The code change was small, a handful of lines here and there but it impacted a number of components of an insurance system in a number of ways, so had to be tested very thoroughly. Another time there was a bug that involved a parenthesis in the wrong place. Took 2 hours to find it, 2 seconds to fix it, but about a week to test dozens of scenarios that may have been affected by the change in logic.

In general, I don't worry about the ratio of time spent coding to time spent testing because there's just no way to be accurate. I find that in some projects, a project-relative ratio appears that is usually standard (to the project), but even then that can change later.

Spend as much time as is needed to say with confidence that the code works properly.


How about you spend enough time writing the tests until you've shown that the feature works as intended, or the bug has been correctly fixed.

Every situation will be different; there cannot be some kind of ratio. Some tests will take a tenth the time as the implementation, others will take hundreds of times as much time.

  • This is the real answer. – DJClayworth Jun 16 '11 at 16:53

I once did a survery after introducing unit tests in a project. The result: time spent writing tests was about 40% again as much as time spent implementing. But we weren't aiming for full coverage there, and it was a well-established project with strong structure and conventions.


I'd say the time coding vs. the time writing unit tests should be approximately equal. Maybe a little bit more sometimes. Take a look at this article on SO Ratio of time spent on coding versus unit testing


Are you counting right? In order to do an accurate accounting of how much time you spend on tests you need to write the code without the test.

If it really took you three hours to write the test and one to write code for it to pass, you may find that it takes 5+ hours to fix the same bug without writing tests.

Yes, I very much often spend much more time on the test than the actual fix code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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