Ratio of time spent on coding versus unit testing

Question

What is a typical estimate for coding unit tests given an estimate for coding new functionality? Is this different for estimates to maintain code?

Answer 1

My time is about equal between time for unit testing and time for functional code.

Some people would look at this and say that is a waste of time, but if your only other option is to run the app and step through all the possible paths the app can take, then the time spent on unit testing is actually less than the time you would spend on developer testing. Of course if you don't do much developer testing, then you will spend the time in fixing bugs that come back from QA.

Either way the time spent writing unit test actually saves time from the amount I would spend on the project.

When it comes time to maintain the code (slight changes, small additions in functionality), there might be a difference. If the code being changed is already fully covered and your changes do not require changes to the tests, then your time is 0. Otherwise obviously it is not, probably closer to equal again.

But, your time savings in testing time is MUCH larger; you've already created the tests to cover the rest of the code, so you would uncover any incidental changes flowing from your change without any new code or walking the app.

Answer 2

i'd say i spend about 50% of the time coding unit tests. it's hard to measure it's gain except from personal experience, but i find it offers 3 main benefits:

• forces you to think about your design more, and you tend to write better code as a result
• allows you to re-factor/maintain many months/years down the line without being scared you'll break everything
• reduces the overall project time spent, as you're not wasting your time hunting down trivial bugs that unit testing would have caught

Answer 3

I find that it varies a lot depending on the code you are working with - when writing something from scratch, test driven, it probably takes about the same amount of time to implement the feature as without tests, but you save longer term on the quantity of bugs that will be found, and how easily you can maintain and extend that code base. One might argue it is faster in this case to write with tests, as you avoid those head-scratching moments where the code just doesn't behave as expected and you have to use a debugger to find out what's going on, over a much wider change set than TDD would typically allow.

When you are trying to implement features on top of an existing, "legacy" code base (as Michael Feathers would define legacy), it often takes significantly longer to implement the feature with tests than without, due to the amount of careful refactoring that must be done before writing tests is typically possible. In this case, writing units tests will still be of long term benefit, but you must put extra thought into whether that long term benefit is justified for the immediate cost.

Generally, I would always push for some form of automated testing, whether unit or functional, despite the additional costs for legacy code bases. Without it, you are likely to find yourself stuck with a code base that is very difficult to maintain and requires constant, repetitive manual testing to ensure it continues to function, with frequent regressions.