How does unit testing improve productivity?

Question

I'm currently looking for ways to improve the productivity of our team. I've read in a number of places that unit testing can be used to improve productivity. I can imagine writing unit tests now can be helpful in the future, but does it help in the short term too? Because I don't understand how writing more code (=more potential bugs) can help us meet deadlines.

Answer 1

Unit testing is not about producing more lines of codes per day.

It is to ensure that every day, your new lines of code don't cause more bugs.

You need to be very careful about what you mesure when you try to evaluate your "productivity". It might help you meet your deadlines however, since you will spend less time fixing stuff.

It is not something aimed for the "short term" as in "we'll use unit testing and our next project will be done in 80% of the time".

Answer 2

Not short term, but not long term either, having automated tests will allow you to detect problems (regressions) caused by wrong bug-fixing, or wrong-developments, faster ; and that is definitly nice.

It means when your application is in testing phase, each time a bug is corrected, you have less risk of introducing new ones.
And that is also true as long as the application is still in development : each time a developper commits a new module, you know it doesn't break the rest of the application (or, at least, that it doesn't break what is covered by automated tests)

And the sooner a bug is detected, the simpler and less costly it is to fix : if a bug doesn't have time to impact other developpers, it is way better too.
What if a developper considers some "bug" (which he doesn't know is a bug) as a feature and start relying on it ? What happens when this starts to be considered as a bug, and is fixed ? The other code breaks, I suppose :-(

Nice thing is also that developping automated-tests can mean more developpers know more about the code of the application : especially if some tests are developped / reviewed by other developpers than the ones who wrote the code in the first place.
Not sure it is "good pratice", but if done this way, it means there will be some kind of code-review in place -- and those are definitly helpful.

And as more developpers know the code, more developpers will be able to fix bugs in parts they did not develop initialy.