What they're testing
Whether you notice that an over-mocked test stays green while the code is broken.
The short answer~30 seconds
I mock what's outside my control and what makes a test slow or non-deterministic: third-party APIs, the system clock, randomness, outbound email. I do NOT mock the database — running a real one in a container gives far more confidence, because most real bugs are in the queries rather than in the code calling them. The sign of over-mocking is refactoring without behaviour change and watching ten tests go red: they're coupled to the implementation rather than the outcome.
The long answer
With third-party APIs, mocks carry a specific risk: they encode your assumptions about that API at the time of writing, and those assumptions go quietly stale when the other side changes. The tests stay green and production breaks. Mitigate with contract tests run periodically against the real API, or by recording real responses rather than hand-writing them.
On clocks, this is worth investing in early: inject time rather than calling Date.now() directly, so edge cases become testable — token expiry, transactions crossing midnight, timezone changes. These are also bugs that are very hard to reproduce in production, so making them testable is worth more than it looks.
What they'll ask next
?Stub, mock, fake, spy — how do they differ?
A stub returns canned values. A mock additionally asserts HOW it was called. A fake is a real but simplified implementation (an in-memory repository). A spy wraps the real thing and records calls. Fakes usually produce the most readable tests because they don't couple to call details.
These lose points
- Mocking the class under test. Then the test proves the mock works and says nothing about the code.