Avoiding mocks, Part I

Mocks often result in brittle tests that simulate unrealistic scenarios, replacing too much of the actual system and providing a false sense of safety.

Photo by Sam Moghadam Khamseh on Unsplash

The solution combines testing vertical slices, relying on dogfooding, and using fakes. Let’s see why and how. We’ll start with how we’d observe queries and commands.

📝 The query/command separation principle distinguishes between queries and commands within a system. Queries retrieve information about the system’s current state but do not modify it (don’t confuse them with database queries). Commands mutate the system’s state but do not return any information. We can categorize every operation as a query or a command (it can’t be both). For example, a query can be a function to sum two values, get profile details REST API, or view bank movements in a UI; a command can be updating a database, sending an email, or transferring money. Printing something in a CLI is also considered a command because what matters is the side effect, not its return.

A test targets a unit (it should be seen as one of its clients). The unit exhibits behaviors exposed through interfaces (APIs, CLIs, GUIs, …). Only the interface can be used by the tests; the rest are details that can be freely changed.

Our test subjects will be software behaviors as observed from the outside.