Shared dependency

As explained in Unit Testing Principles, Practices, and Patterns

A shared dependency is a dependency whose internal state is reused or accessible across multiple tests.

A shared dependency is a dependency whose state is reused by multiple tests and gives those tests a way to affect one another’s outcomes. Typical examples include a static mutable field, singleton, or database. section 2.1 section 2.2

Classify dependencies by whether tests can share and mutate their state:

• A private dependency is not shared between tests; a mutable Store instance can remain intact when each test creates its own instance. section 2.1 section 2.2
• An out-of-process dependency runs outside the application process, but it is shared only when tests reuse the same mutable instance. section 2.1 section 2.2
• A read-only database or API can be out-of-process without being shared because tests cannot mutate it or alter one another’s execution. section 2.1 section 2.2
• A value object is private and immutable; Product.Shampoo and the number 5 are dependencies but not collaborators. section 2.2

Parallel database interference

One test creates a customer during arrangement while another deletes that customer before the first finishes. Running them in parallel can make the first test fail even when the production code is correct. Shared database state therefore requires isolation measures, such as replacing the dependency or running tests sequentially. section 2.1 section 2.4

The classical school isolates tests from one another, replacing only shared dependencies with test doubles. The London school isolates the class under test from all mutable dependencies, including private ones. Keeping private dependencies intact can preserve broader behavior-focused tests while avoiding shared-state interference. section 2.2 section 2.5

Figure 2.3. Isolating unit tests from each other entails isolating the class under test from shared dependencies only. Private dependencies can be kept intact.

Shows the isolation boundary: shared dependencies are replaced with test doubles, while private dependencies can remain intact. section 2.1

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes

Defines shared, private, and out-of-process dependencies, then contrasts isolation policies and parallel-execution consequences.

Examples

Uses static mutable fields, singletons, databases, read-only APIs, Store instances, and parallel database tests as concrete contrasts.

What it assumes

Assumes basic unit-testing knowledge and distinguishes mutable, immutable, shared, private, and out-of-process dependencies.

What you can do after

Apply dependency classifications to decide when tests need doubles, separate instances, or sequential execution.

How it connects

Connects shared dependencies with unit testing, test doubles, private dependencies, out-of-process dependencies, collaborators, and integration testing.

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.
• classical schoolused by · A unit-testing approach, also called the Detroit school or classical style, that isolates tests from one another while allowing the unit under test to use real collaborator objects.
• out-of-process dependencyequivalent to · 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.
• test isolationcontrasts with · Test isolation is the property or practice of executing tests independently so their outcomes are not affected by other tests, shared state, dependencies, or external conditions.
• 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.