Out-of-process dependency

As explained in Unit Testing Principles, Practices, and Patterns

An out-of-process dependency is a dependency that runs outside the application's execution process and provides access to data or services external to in-memory execution.

An out-of-process dependency runs outside the application's execution process and provides access to data or services not yet held in application memory. Databases and file systems are typical examples. Because tests communicate with them across a process boundary, they are usually slower than in-memory dependencies. section 2.1 section 2.4

Distinguish the dependency's process location from whether tests can interfere through it:

• A database is both out-of-process and shared when tests can modify the same instance and affect one another. section 2.1
• A database started in a Docker container for each test run remains out-of-process but is not shared between test runs. section 2.1
• A read-only product API is out-of-process but not shared because tests cannot modify its returned data. section 2.2
• A shared dependency can also remain inside the process, such as a reused singleton or static mutable field. section 2.2

Out-of-process dependencies shape the boundary between unit and integration testing. Tests that reach a database or other shared dependency lose speed or isolation; replacing that dependency with a test double can preserve both. Integration tests retain selected real dependencies to verify controllers and system-level integration, while unit tests cover domain logic and algorithms. section 8.1 section 8.8

Database-backed customer test

If one test creates a customer in a shared database while another deletes it during setup, parallel execution can produce a failure unrelated to production-code correctness. Running such tests sequentially or isolating the database instance removes that interference, but direct database communication still carries a speed and maintenance cost. section 2.1 section 2.4

Figure 2.5. The relation between shared and out-of-process dependencies. An example of a dependency that is shared but not out-of-process is a singleton (an instance that is reused by all tests) or a static field in a class. A database is shared and out-of-process—it resides outside the main process and is mutable. A read-only API is out-of-process but not shared, since tests can’t modify it and thus can’t affect each other’s execution flow.

Use this relation map to compare shared and out-of-process dependencies, including databases, read-only APIs, singletons, and static fields. section 2.2

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes

Defines process location, distinguishes sharing and immutability, and connects the classification to speed, isolation, and integration-test trade-offs.

Examples

Uses databases, file systems, Docker-isolated databases, read-only APIs, SMTP servers, and message buses as contrasting examples.

What it assumes

Assumes familiarity with unit tests, integration tests, shared state, and test doubles while defining dependency categories explicitly.

What you can do after

Evaluate/understand when to use real dependencies, isolate instances, run integration tests, or substitute test doubles.

How it connects

Connects out-of-process dependencies to shared dependencies, test doubles, unit testing, integration testing, managed dependencies, and unmanaged dependencies.

liveBookmanning.com

Read Unit Testing Principles, Practices, and Patterns on liveBook Get the book at manning.com

Related concepts

• integration testused by · An integration test evaluates whether multiple software components, or a component and an external dependency, interact and behave correctly together.
• unmanaged dependencyincludes · An unmanaged dependency is an out-of-process dependency whose interactions are observable by external systems and that is not fully controlled by the application.
• managed dependencyincludes · A managed dependency is an out-of-process dependency that is fully controlled by the application and accessible only through that application.
• infrastructure layerused by · An infrastructure layer is an architectural layer that provides technical capabilities and connects application functionality to resources such as databases, messaging systems, and external services.
• shared dependencyequivalent to · A shared dependency is a dependency whose internal state is reused or accessible across multiple tests.
• private dependencycontrasts with · A dependency that is not shared between tests and therefore cannot transmit state between their executions.

This explainer was generated by Manning's knowledge graph from the text of Unit Testing Principles, Practices, and Patterns. The section links point to the parts of the book it draws on.