An outgoing dependency is an exit point from a unit of work: the unit calls, sends, saves, or notifies something outside itself. Logging, database writes, emails, APIs, and webhooks are typical examples. The action flows outward, often in a fire-and-forget manner. section 3.1
Do not confuse an outgoing dependency with an incoming dependency. An incoming dependency supplies data or behavior, such as a query result, file contents, or network response. Mocks replace outgoing dependencies and are checked to confirm that the expected exit point was used; stubs replace incoming dependencies without asserting against them. section 3.1 section 3.8
Checking an external notification
A unit that handles an event might call notifier.send(event). In a unit test, replace notifier with a mock and verify that send was called. The mock represents the outgoing dependency and the notification is the unit's indirect output. section 3.1 section 3.8
Practical consequences:
- Use mocks when the test must verify that the system under test changed or notified an external dependency. section 3.8
- Remember that one dependency can be incoming in one test and outgoing in another, although this is uncommon. section 3.1
- Choose an injection technique deliberately: function parameters, factories, module replacement, constructors, object parameters, or common interfaces. section 3.8
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 invoked exit point from a dependency that supplies indirect input or behavior. section 3.1
