Test Double Boundary
The line inside a test between what is real and what is substituted, which determines exactly what the test can and cannot prove.
Every test draws a boundary. Inside it, real code runs; outside, doubles stand in. The boundary is the test's specification of what it proves, and it is usually implicit, which is why so many suites are simultaneously slow and uninformative.
Move the boundary outwards — real database, real message broker, real HTTP client against a stub server — and the test catches serialisation errors, migration mistakes, transaction scope bugs and driver behaviour. It also gets slower and gains setup cost.
Move it inwards — mock the repository, mock the client — and the test is fast and proves only that the code calls its collaborators as the author expected. That is worth something for complex logic and nothing at all for a data access layer, where the mocked expectation is a restatement of the implementation.
The rule that survives contact: never mock what you do not own. A double for a third-party client encodes your belief about that client's behaviour, and your belief is exactly what the test was supposed to check.