Reproducibility means capturing a function’s context so its behavior can be recreated elsewhere. With immutable data, that context is the values of its arguments: the same values produce the same result. section 15.1 section 15.7
Imagine debugging a web search. You trigger an endpoint, but the failing function sits deeper in the call stack. A breakpoint reveals a query and a huge nested catalog; copying those values into a REPL lets you investigate without repeatedly invoking the endpoint. section 15.1
A practical reproducibility loop looks like this:
- Capture the function arguments when the real scenario occurs. section 15.3
- Serialize complex data, such as nested maps, so it can be copied or stored. section 15.1 section 15.7
- Replay the call in a pristine REPL environment and iterate with a short feedback loop. section 15.3
- Store captured inputs with the tests when they expose useful production conditions. section 15.4
Replaying a book-search failure
Capture catalogData and query when Catalog.searchBooksByTitle runs. Replaying the captured catalog with "Habit" exposes an empty result; after changing matching behavior, the same fixture returns 7 Habits of Highly Effective People. The fixture can then drive tests for case variations and valid or invalid prefixes. section 15.3 section 15.4
External data complicates the promise. A changing database or service can return a different response for the same query. Immutable or append-only databases preserve reproducibility by querying unchanging snapshots; otherwise, local debugging depends on the data remaining stable. section 15.5
Table 15.1 REPLs per programming language (view table figure)
Use a language REPL to execute captured calls interactively; available examples include browser JavaScript, Node.js, JShell, C# REPL, Python, and Ruby. section 15.1
