dotNetDave Says… If Your Code Is Hard To Unit Test, You’re Doing It Wrong!

Unit testing is one of the most important practices in any software project. And yet, in my experience, it’s rarely done—or done well. Too often, teams push code to quality assurance or straight into production without truly knowing the state of that code.

Ask yourself this: how can you responsibly deploy software if you have no automated way to verify that it actually works?

A few years ago, I worked on a contract at a company in San Diego, California. Shortly after I started, two managers approached me and told me they were going to give me access to the production servers so I could push code directly. My first question was simple:

“Do these projects have unit tests?”

Their answer was no.

I immediately told them I wasn’t comfortable being responsible for pushing code to production without unit tests in place. If something went wrong, I didn’t want to be the one holding the bag. Unsurprisingly, I didn’t last very long there—though that wasn’t the only reason.

Let’s be honest: most developers don’t want to write unit tests. They aren’t flashy. They aren’t features. They don’t sell products. But they are absolutely critical.

Unit tests give you confidence. They tell you whether changes broke existing behavior. They allow teams to refactor safely. And they act as living documentation for how the code is supposed to behave.

From conversations I’ve had with engineers at Microsoft, a common guideline is to aim for at least 75% code coverage. That number isn’t magic, but it’s a strong indicator that testing is being taken seriously.

Think of unit testing like going to the doctor for a routine check-up. No one looks forward to it, but skipping it doesn’t make problems go away—it just means you discover them later, when they’re far more expensive and painful to fix.

Pushing untested code into production is the software equivalent of ignoring warning signs and hoping everything turns out fine. Sometimes you get lucky. Most of the time, you don’t.

Unit tests aren’t about perfection—they’re about responsibility. If you care about quality, stability, and your own professional credibility, testing isn’t optional. It’s part of the job.

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.