Testing the Seams
Good seams make behavior testable without turning the test suite into a wiring diagram.
A seam is not automatically a mock. It can be a function value, a small interface, a clock, or a directory path. The point is to give the test a controlled place to stand while the rest of the code behaves normally. Too many seams make a system hard to follow; too few make it hard to observe.
The useful question is not how to inject everything, but where variation actually matters. Time, randomness, network access, and filesystem boundaries are usually worth naming. Pure transformations can stay pure. That balance keeps tests close to the behavior they describe and keeps production code from becoming a collection of hooks.