liveBook · Manning

Volatile dependency

As explained in Unit Testing Principles, Practices, and Patterns

A dependency that requires extra runtime-environment setup or produces nondeterministic results.

A volatile dependency either requires runtime-environment setup beyond a developer’s default installation or produces nondeterministic results. Databases, API services, random-number generators, and current-time providers are typical cases. section 2.1

Distinguish volatility from sharing:

  • A database is both shared and volatile because it requires external setup and can be reused across tests. section 2.1
  • A file system is shared but usually not volatile: it is commonly available and behaves deterministically, yet tests can interfere through its state. section 2.1
  • A random-number generator is volatile because repeated invocations can return different results, even when tests do not share it. section 2.1

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes
Defines two volatility criteria and contrasts them with shared dependencies, without detailing implementation techniques.
Examples
Uses databases, API services, random-number generators, current-time providers, and file systems as contrasting examples.
What you can do after
Apply it via test doubles to isolate unit tests from environmental setup and nondeterministic behavior.
How it connects
Connects volatile dependencies with shared dependencies, dependency injection, test doubles, and unit-test isolation.
Cover of Unit Testing Principles, Practices, and Patterns
liveBookmanning.com
Read Unit Testing Principles, Practices, and Patterns on liveBook Get the book at manning.com

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.