tdd-mock-object

One-line summary

Use a test double to replace a real collaborator that's too slow, too external, or too non-deterministic to call from a test. Reach for it reluctantly — over-mocking couples tests to implementation rather than behavior.

When to use this skill

• A test would otherwise touch a database, a network, a file system, a message broker, or any other "outside the JVM" resource.
• A test would otherwise depend on system time, randomness, or other non-deterministic sources.
• A test would otherwise call a third-party API that's slow / paid / rate-limited.
• You want to verify that a collaborator was called correctly (e.g., a notifier was triggered).

When NOT to use this skill

• The dependency is fast, deterministic, and in-process — just use the real thing.
• You're mocking a class you own whose behavior is the thing being tested. That's testing the mock, not the code.
• You're mocking a value object or data structure — overkill; construct the real one.
• You're mocking everything in sight and your tests are now mostly mock setup. The design needs simplification before more mocks.

Core content