Test isolation
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.
Unit Testing Principles, Practices, and Patterns
The property of executing a test independently so that other tests or external influences cannot affect its outcome.
- How it is used
- Defines the quality goal behind unit tests and frames the classical-versus-London disagreement.
- How deep it goes
- Contrasts two isolation boundaries, demonstrates each with inventory tests, and links mocks to fragility and refactoring resistance.
- Examples
- Uses inventory-purchase tests to contrast concrete state verification with mocked interaction verification.
- What you can do after
- Evaluate isolation strategies and apply test doubles while accounting for parallel execution, shared dependencies, and refactoring resistance.
Read how Unit Testing Principles, Practices, and Patterns explains test isolation →
100 Go Mistakes and How to Avoid Them
Test isolation is the property that a test's outcome does not depend on state or execution effects from other tests.
- How it is used
- Uses dependency design to prevent time-based tests from sharing mutable state and to preserve safe parallel execution.
- How deep it goes
- Explains the failure mode and contrasts injected clocks with caller-provided timestamps, without detailing broader test frameworks.
- Examples
- Uses a Cache trimming events, a global now variable, an injected clock, and fixed timestamps in unit tests.
- What you can do after
- Evaluate time-dependent tests and choose injected dependencies or caller-provided timestamps to make their outcomes deterministic.
Read how 100 Go Mistakes and How to Avoid Them explains test isolation →
The Art of Unit Testing 3e
Test isolation is the property that each test runs independently without relying on or altering the state or execution of other tests.
- How it is used
- Protects test-suite trustworthiness by preventing tests from affecting one another through shared state or execution order.
- How deep it goes
- Explains order dependence, demonstrates shared-cache failure, and refactors setup with beforeEach; it stops short of broader runner mechanics.
- Examples
- Uses a shared UserCache, SpecialApp login tests, test.only, and beforeEach reset as concrete artifacts.
- What you can do after
- Diagnose order-dependent failures and refactor tests to reset shared state and arrange their own required data.
Read how The Art of Unit Testing 3e explains test isolation →
Related concepts
- integration testcontrasts with · An integration test evaluates whether multiple software components, or a component and an external dependency, interact and behave correctly together.
- change failure rateproduces · Change failure rate is the proportion of deployed software changes that cause failures requiring remediation, rollback, recovery, or other corrective action.
- mean time to resolutionproduces · Mean time to resolution is the average elapsed time from identifying or reporting an issue, failure, or incident until it is resolved or affected service is restored.
- mockingaddressed by · Mocking is a testing technique that replaces a real dependency with a controlled substitute to simulate behavior or inspect interactions.
- goroutineuses · A goroutine is a lightweight function execution unit managed by the Go runtime that runs concurrently with other program activity.
- reliabilityaddresses · Reliability is the ability of a system or process to perform its intended functions consistently and dependably under specified conditions and over time.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.