Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Economics of Unit Testing

DZone's Guide to

The Economics of Unit Testing

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

 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.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}