Dependency Injection

Dependency injection supplies a dependency from outside the component that uses it. A workflow can receive a reader and publisher rather than constructing a database client inside its transformation.

In a small Python program, ordinary function parameters can provide this boundary. Pass a recording publisher in a unit test and a database publisher in deployment. A dependency-injection container is optional, not part of the definition.

The boundary still needs a contract: input and result types, error behavior, transaction ownership, and who closes resources. Two functions with the same signature may have different retry or publication effects.

A fake can demonstrate that invalid rows never reach publication. It cannot demonstrate real authentication, SQL compatibility, atomicity, or network recovery. Test the real adapter separately and keep wiring visible enough to identify the actual destination.

If run receives read_rows and publish_rows, a test reader can return two known records and a test publisher can record its arguments. The test then checks both the computed rows and whether publication was called. Construct the real clients at the application boundary and pass them in there. A hidden global client inside the transformation defeats that substitution even if other parameters are injectable.

See Designing Maintainable Data Workflows for worked examples.

Further reading

• Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern