Your objects (or functions) tend to have collaborators, and when you test those objects (or functions) you want to verify their operation without having to worry about those collaborators.
There’s generally three ways to do this.
The first is to make all of your objects observable including the collaborators. An observable object is like a pizza oven with a little window in the middle of its run. For the most part it just does its job, but when you need it, you have a window into how it’s operating. Note I didn’t say a window into its internal data. If you care about that, your design is off. I said that the object gives you the observability to understand the behaviors it’s carrying out.
The second is to just let the side effects happen and observe where those side effects happened or use some mechanism to record the side effect and hope that the recording never needs to change. Here’s looking at you, ActiveRecord and vcr.
The third way, which is probably what you reach for if you didn’t do the first way, is to replace the collaborator objects with mocks objects. A mock object is something that you’d write as a tester of a unit of software to replace some operational, side-effect inducing object with an inert version of that object. In theory, this mock object would also provide observability into the operations it’s “carrying out.”
And then, if you’re really dialing up this second way to 11, you might end up mocking the unit under test too so that your test is testing your mocks and not your actual code. So then your test suite passes, but your deployments fail. Fun times.
If you can’t tell from my cynical tone, I much prefer approach #1. Now before you say, “that’s difficult, and I need to ship things,” let me pre-object with two points. First, it’s not difficult, but it may be unfamiliar. Getting familiar with making code observable is more worth your time than learning a type system. The second, observability, usability, and quality go hand-in-hand, and high quality is what enables moving quickly. When you’re debugging your not-tested-because-of-too-many-mocks production code, you’re not delivering value to your customers.
Tonight’s meetup is literally about showing how to make your objects observable. We’ll use Eventide’s Telemetry and Dependency libraries to do so, and we’ll do it in about an hour. I’d like to think you can help your teams find an hour so that they can save tens of hours later.
But we’ll also cover how to do that has we progress through the TDD series we’re in the middle of. I needed the diagram above to prepare for the meetup tonight, so I just made the email about that diagram. That, my friends, is a twofer.
