Unit testing is part of the job
In one of my unit testing courses we had a disucssion I’ve been part of what feels like a million times.
The question the team asked was: “How do you convince the client to pay for unit testing?”
Because it adds like 20% more to the project’s budget, right?
While we can discuss the validity of the number, the interesting thing is what lies behind the question about “the added cost of unit testing”.
It’s an add-on!
Imagine going to a client, and saying “we can do the project cheaper, we’ll just skip the design part”. Does this sound professional? Would any client accept a system that didn’t go through some kind of design?
Even when a client wants a POC or willing to accept a lower quality system, they expect that we’d design it. They will not consider us professional if we’d provide them something that wasn’t properly thought through.
We don’t talk about design as a separate, possibly patched-on section in the project, because we consider it a part of the job.
But, unit testing? Sure, we can add or drop it for the right price.
It’s not “production code”. It doesn’t even get delivered. It’s a novelty that people hear about in conferences but makes developer lives in the real world harder.
Whatever the excuse is, it becomes a separate line-item in the project plan.
If we continue talking about unit testing like an add-on to coding, it’s easy to see how we get to these conversations regularly.
Enough is enough
Unit testing is an integral part of development process. It is not something you drop to make the deadline. It’s part of the project, a part of regular development work. It’s like writing code, designing, testing, documentation – any other part of the project.
Writing code (sometimes horrible, complex code) is part of the job. It has its cost (writing, maintaining, reviewing, fixing). It has its value (working functionality).
Well, guess what. Unit testing is the same. It is one of the things we do to produce working software.
Unit testing is simply a part of the job.