Writing good unit tests is made much easier by dependency injection. This lets you separate your code’s behavior from that of your dependencies.

Many people use mocks to add dependencies to unit tests. I think this is usually a mistake.

This article was originally published on gopheradvent.com Looking in Go’s mirror: How and when to use reflect Go’s static typing is a headline feature of the language. It prevents whole classes of bugs, makes code easier to navigate and refactor, and makes it easier for linters to analyze. But there are times when it’s very constricting. What if we’re reading JSON files from disk with unknown structure? We can’t define a type ahead of time that will cover all cases.

In the last blog, I wrote a few things that software is for:

• putting people on the moon
• safely deploying airbags
• making my bank account add up

…

Once a month or so, this idea comes rambling out of the programming community1: Software is prose. It is written to communicate ideas to others, it has the interesting side effect that it can be transformed into something a computer can execute. - Chet Hendrickson This sounds nice on paper. It makes for a good conference talk about how to structure software, how to design programming languages, and how to collaborate.

At work I’ve been building a new program on top of an SDK that’s under very active development. After about 6 weeks without updating the version, the SDK had deleted some code I was using and had a ton of breaking changes. If I’d simply updated the library, my entire program would fail to build, and it also wouldn’t be clear how to get it back to a good state. Following in the spirit of Branch by Abstraction, I’d rather introduce the new code side-by-side with the old and incrementally migrate without breaking the program.