Attributes, Not Names

Names are imperfect and often problematic. Personally, I’m not a fan of terms like “unit tests”, “integration tests” or even “acceptance tests”. They always seem to carry slightly different meanings depending on the context.

I prefer to focus on the attributes of tests. That’s why I think we need a testing hypercube, not just a testing pyramid: multiple dimensions defining tests as fast/slow, wide/deep, deterministic/non-deterministic, and so on.

A test can occupy a combination of these dimensions.

I see different test suites as different lenses, each with its own level of magnifying power. That’s why, in a project, we often need multiple suites of different types.

Acceptance tests might address a specific behaviour at a certain level of magnitude, while the smaller blocks of logic that make up that behaviour can still be verified with unit tests.

So, yes: I turn the engine on and I want to check that vibrations are safe, noise stays below a threshold, and emissions are within limits. But I also want to watch how the pistons move, and within them, whether the compression rings are wearing out and the fuel is being pumped correctly.

A diligent team ensures they have all the required layers of observability to narrow down problems quickly and intervene effectively.

Originally posted on LinkedIn.