An incoming dependency supplies data or behavior to a unit of work without representing its eventual externally observable result. It provides indirect input flowing inward, such as a database query result, file contents, or a network response. section 3.1
The useful contrast is an outgoing dependency: an exit point where the unit of work calls a logger, saves data, sends email, or notifies another system. Incoming dependencies are normally replaced with stubs and not asserted; mocks represent outgoing dependencies and are checked for calls. section 3.1 section 5.6.3
Injecting a test-specific result
A JavaScript unit of work can accept a function as a parameter: `function unitOfWork(query) { const result = query(); /* use result */ }`. A test can pass a stub such as `() => testSpecificData`, supplying controlled input without asserting that the stub was called. The same dependency can occasionally be incoming in one test and outgoing in another, although that should be uncommon. section 3.1 section 3.8
Common ways to inject an incoming dependency include:
- Pass a function, use partial application or a factory, inject a module with the same API, or provide a constructor dependency. section 3.8
- In JavaScript, pass an object implementing the required functions; in TypeScript, use a shared interface with compile-time checking. section 3.8
- Prefer input control over interaction checking: verifying that an incoming dependency was called is an overspecification antipattern. section 5.6.3
Figure 3.1 On the left, an exit point is implemented as invoking a dependency. On the right, the dependency provides indirect input or behavior and is not an exit point.
Use the figure to distinguish an exit point from a dependency that supplies indirect input or behavior. section 3.1
