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.