Glossary

A collaborator is an object that another object depends on and talks to in order to perform its function – a dependency it delegates part of a job to. If a ReportService asks a Clock for the time and a Repository for the records, the clock and the repository are its collaborators.

Dependency injection (DI) is a technique where an object receives the collaborators it needs from the outside – typically during construction – instead of constructing or looking them up itself. The object depends on an abstraction (an interface, protocol, trait, etc) and the concrete implementation is supplied by the caller that constructs it.

The Dependency Inversion Principle (DIP) is the “D” in the SOLID principles. It states that high-level modules should not depend on low-level modules – both should depend on an abstraction – and that abstractions should not depend on details. The “inversion” is that the low-level detail ends up depending on an interface owned by the policy, rather than the policy depending on the detail.

A dummy is a test double that exists only to fill a required parameter on a code path that never uses it. It is the simplest member of the family: it carries no behavior, returns nothing meaningful, and is never configured or asserted on – a placeholder passed purely to satisfy a signature.

A fake is a test double with a real, working implementation – just one that takes a shortcut unsuitable for production, such as an incrementing counter standing in for a database sequence. It carries genuine, evolving state, so a unit gets realistic behavior from it and the test asserts on the outcome that behavior produces.

The Interface Segregation Principle (ISP) is the “I” in the SOLID principles. It states that no client should be forced to depend on methods it does not use. Prefer several small, focused abstractions over one large one, so that each consumer depends only on the operations it actually calls.

The Liskov Substitution Principle (LSP) is the “L” in the SOLID principles. It states that an object of a supertype must be replaceable by an object of any subtype without breaking the program. A subtype has to honor the supertype’s contract: it may not strengthen what the caller must provide, nor weaken what the caller is promised in return.

A mock is a test double that is preconfigured with expectations about how it should be called, and which verifies those expectations during a test. Where a stub simply returns canned values, a mock asserts on the interactions – which methods were invoked, with what arguments, and how often.

The Open/Closed Principle (OCP) is the “O” in the SOLID principles. It states that a software entity should be open for extension but closed for modification – you should be able to add new behavior without editing the code that already works. A switch that grows a new branch every time a variant is added is the canonical violation.

The Single Responsibility Principle (SRP) is the “S” in the SOLID principles. It states that a unit of code should have exactly one reason to change – that is, it should answer to a single actor or concern. A class that computes prices, formats a document, and writes files has three reasons to change, and therefore violates it.

SOLID is a set of five object-oriented design principles, popularized by Robert C. Martin, for structuring code so that it tolerates change without cascading edits. Each principle attacks a specific way a design goes rigid: a class that changes for too many reasons, a module you cannot extend without editing, a subtype that breaks its callers, an interface that forces dead code on its implementers, or a high-level policy welded to a low-level detail.

A spy is a test double that records how it was called so the test can inspect those calls afterwards. It is a stub with a memory: it can still return canned answers, but it also captures the arguments, order, and count of the calls it received, and leaves the judgment to the test.

A stub is a test double that returns canned, pre-arranged answers to the calls a unit makes during a test. It supplies the inputs a unit needs from a collaborators – a configured user, a fixed exchange rate, an allow-or-deny decision – without the cost or nondeterminism of the real thing. Unlike a mock, a stub makes no assertions of its own; it only feeds the unit so the test can check what the unit does with the answer.

Test double is the umbrella term for any object that stands in for a real collaborator during a test – just as a stunt double stands in for an actor. The family includes dummies, stubs, spies, fakes, and mocks, each substituting a real dependency to keep the unit under test isolated and deterministic.