Managed dependency

As explained in Unit Testing Principles, Practices, and Patterns

A managed dependency is an out-of-process dependency that is fully controlled by the application and accessible only through that application.

A managed dependency is an out-of-process dependency fully controlled by the application and accessible only through it. Because external clients cannot observe its interactions, those communications are implementation details; the dependency’s final state is what matters. section 8.2 section 8.8

Use the classification to choose an integration-testing strategy:

• Use a real instance of a managed dependency, such as an application database, rather than mocking its interactions. section 8.2
• Run the integration test through every application layer that works with the dependency, then verify its resulting state independently of the input parameters. section 8.8
• Treat an externally visible portion of a dependency as unmanaged: mock that portion, while testing the privately controlled remainder through its final state. section 8.8
• Inject managed dependencies explicitly, but use concrete classes; reserve interfaces for unmanaged dependencies or genuine abstractions with multiple implementations. section 8.4

Testing a database-backed email change

Create a real database, insert a user and company, execute the email-change scenario, and assert the updated email in the database. Mock the message bus separately and verify its interaction, because other systems observe messages sent through it. section 8.3

Figure 8.5. Treat the part of the database that is visible to external applications as an unmanaged dependency. Replace it with mocks in integration tests. Treat the rest of the database as a managed dependency. Verify its final state, not interactions with it.

Use the figure to distinguish an externally visible database surface, which is treated as unmanaged, from the privately controlled remainder, whose final state is verified. section 8.2

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes

Explains observability, test strategy, mixed dependencies, injection, and a concrete database workflow; it defers detailed database setup and transaction management.

Examples

Uses application databases, a user-email change scenario, a message bus, real database assertions, and mocked message interactions.

What it assumes

Assumes familiarity with integration testing and out-of-process dependencies while teaching the managed-versus-unmanaged classification from its observability criterion.

What you can do after

Apply it via integration tests that exercise real managed dependencies and verify their final state after business scenarios.

How it connects

Connects managed dependencies with integration testing, unmanaged dependencies, mocks, databases, observable behavior, and end-to-end testing.

liveBookmanning.com

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

Related concepts

• application databaseincludes · An application database is a database accessed exclusively by a particular application and hidden from direct access by external systems.
• out-of-process dependencykind of · 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.
• integration testused by · An integration test evaluates whether multiple software components, or a component and an external dependency, interact and behave correctly together.
• unmanaged dependencycontrasts with · 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.

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.