The Economics of Unit Testing
The Economics of Unit Testing
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
Unit testing is a set of skills, that rarely appears on a resume. When I saw a resume with unit testing on it, it rose up to the top of the interview queue. I understood the person who put it there understand what it means to the business.
If the organization already took the red pill, it sees unit testing like this:
Unit testing shortens the current and future release cycles at the expense of initial extra development work.
It's not about quality, or maintenance, or other things we'll dive into more in a minute - it's about money: Shortening the release cycles means earlier income. For the next releases it also means less maintenance money and more money from new features.
The extra development time is not really just in the beginning. It is definitely a bump in the beginning, because the team needs to learn new skills and tools. Once they do learn it, and make it a work process development time even drops. Industry numbers talk about ~20% more work, but this is really subjective.
Let's take an example a project which takes D time to develop. If the project manager is smart, she'll plan an integration period I and testing time T.
With unit testing effort, D increases, while I and T reduce. This is because bugs get caught earlier, and are also easier to debug, because of the tests.
But this is only for the first release. Let's see what happens in the next release. Without unit testing, development time is now longer, because we need to fix bugs we didn't fix in the first release. Also, integration and testing are now longer, because we're breaking functionality that worked before and needs fixing again.
So zooming out a bit, two cycles look like this:
That means that with each subsequent release, for basically the same scope, we're delaying the release, making the project late.
With unit testing effort, in the second release there's no additional effort on the Development side, it's now just part of the process. In addition, there are less bugs from the early release, and integration and testing for this release are also shorter, because there are less bugs from this implementation.
The initial investment in training the team for unit testing (and TDD if you’re up to it) may seem that it delays releases. In fact, it does the complete opposite.
The numbers may change, the knowledge and experience may change. The process I illustrated, however, remains the same.
If you thought about how to sell unit testing to business people, this is how you do it.
Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.