You’re building a complex piece of software. Then it comes time to deploy, so you spend a couple weeks stuffing it into a Docker container or a .deb or .rpm package, and debugging the build and deployment process. Then you add some sort of monitoring or logging, set up email or SMS alerts to tell you when it crashes, and probably a dozen other things to make it “production ready.”

This is the second installment in my series The False Dichotomies of Automated Testing. If you’ve ever met a recent test convert, you’ve probably heard them talk about the mythical creature that is “100% test coverage.” As with most benevolent mythical creatures, this one is highly sought after, and possibly even worshiped. It is claimed to have magical powers, although the precise nature of these powers is often hotly debated even among the most ardent of believers.

This is the first in a series of posts about automated testing for software developers. I’ve been fascinated by this thing called “programming” since I first learned I could enter BASIC programs into my family’s Commodore 64 when I was 8 years old. I became a full-time software developer in 2006. And I “got religion” about automated tests shortly after that. But still not everyone is as “enlightened” as I am when it comes to writing automated tests.

A couple of weeks ago I made a comment to my team at work which I think a couple took harshly, but I believe it is true, and an indication of a deeper problem. I said “All of the really smart people at this company move to the ‘infrastructure’ teams within a few years, which means we have only new, untrained people writing the real software.” Today, on a flight back home from vacation in Oslo, I was reading Domain-Driven Design by Eric Evans, and once again I found myself taken aback by how precisely this book has described my work place–and not in a good way!

I wrote this post in October of 2015 as I was adjusting to life without unit tests at a new job. I recently stumbled upon it in my Drafts, and edited it down to a single point for publication. In October of last year I took a new job at a company with a large group of programmers, and an old (15+ years) code base. The new company doesn’t generally do unit tests, for various historical reasons, none of which make much sense upon close examination.

I have a new software project in mind. I want to do it right. So I’ll use a RESTful web API. Which, of course, like any good software developer, I already understood pretty well, but I wanted to just brush up on my REST game, and make sure I got all the best practices down. Thus began my search on Amazon for a good book about REST. I found one. I read it.