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.
David V. Corbin · January 3, 2017 at 3:19 am
I disagree (and I suspect you may also) about the “Because it adds like 20% more to the project’s budget, right?” premise. Repeated experience has shown that it saves *at least* 20% of “straight costs” and may result in much higher numbers if one takes into account various weighting functions.
Do a simple test. Have a developer write two small pieces of code (similar but different). Within an hour of completion, tell the developer there is some change needed to the first piece of code [simulating a bug], measure how long it takes to fix. Wait at least 2 months, then show up with the second piece of code and another simulated bug, again measure the fix time…
David Krauss · January 18, 2017 at 5:13 am
Sometimes you can’t even calculate the cost benefit of unit testing. I work for a company that produces healthcare software. What is the cost of a defect that may be caused by a modification to existing software, but wasn’t caught because there weren’t adequate (or sometimes any) units. And what if that defect allowed data from one patient to be inadvertently accessed by someone else? The financial impact in fines could be far greater than the 20 or so percent of the implementation costs.
JizzInMyPants · January 4, 2017 at 11:01 pm
The problem with testing is the overall indefinition of what a complete testing suite is. When can we classify a feature “100% tested”? How ensure can your client be? How much time will be cut from QofA because your tests are enough?
Not saying that tests aren’t important and on the long run don’t help maintain the code base, but it’s value is rarely perceived by the clients, lots of gigs are fixed-time, they don’t replace QA, and, most important of all, a dev either tests too much (every micro-routine in isolation, acceptance tests, integration tests, regression tests, front-end unit tests, I’ve seen people write tests for language features, let alone framework) or doesn’t test at all.
robi y · January 8, 2017 at 4:27 pm
and of course TDD helps here too, since you write the test timely with (i.e. before) the code, so when reaching the deadline the tests are already there.