evilissimo/software-design
Use before implementing or refactoring software. Contains two skills: (1) Modular Software Design — for designing module boundaries, APIs, layers, abstractions, services, repositories, adapters, or architecture, helping reduce total system complexity by creating deep modules, hiding implementation knowledge, avoiding leakage and pass-through APIs, comparing alternative designs, documenting interfaces before coding, and critiquing existing architecture; and (2) Software Testing — for writing unit tests, integration tests, or end-to-end tests, creating mocks/stubs/fakes, designing a testing strategy, doing TDD, reviewing test quality, fixing flaky tests, or refactoring test suites, generating risk-focused test plans, picking appropriate test levels, choosing between mocks/fakes/real dependencies, and applying Arrange-Act-Assert patterns with concrete examples.
88
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
test-doubles.mdskills/software-testing/references/
Test Doubles Reference
Definitions (Fowler's Taxonomy)
Dummy Only fills a parameter slot. Never actually used.
Fake Has a working but simplified implementation. Example: in-memory store instead of real database.
Stub Returns canned answers for incoming calls.
Spy A stub that also records what happened so the test can inspect it later.
Mock Pre-programmed with expectations about outgoing interactions and verified against those expectations.
Decision Rules
Prefer fakes over heavy mocks when you need realistic behaviour without brittleness of interaction scripting.
Prefer spies or state inspection over strict interaction verification when behaviour can be observed after the fact.
Use mocks when the outgoing interaction itself is the behaviour you care about (e.g., sending an email, publishing a message).
As a default architecture rule: mock or fake types you own or clearly understand. Wrap third-party libraries or remote APIs behind your own adapter before substituting.
Do not mock internal collaborators that are merely part of the unit's implementation. If several small classes together realise one cohesive behaviour, exercising them together produces stronger and less brittle tests.
Do mock, stub, fake, or spy at true boundaries, especially when a dependency is out-of-process, slow, nondeterministic, shared with external applications, costly, or unsafe to use in tests.