A worked design case: changing invoice exports

Consider this design exercise, created for the review. A routine receives a customer ID, retrieves charges, calculates totals, formats CSV and sends it. We want to exclude canceled charges while preserving the order of other rows and the existing rounding rule. This case contains no production data or measured production results.

First map the flow and its effects. The query returns an identifier, status, amount and due date. The destination receives generated content. A reference date determines the reporting period. These are candidate controlled inputs; the transformation between them is the code we want to execute.

If the routine already accepts a query object, use that seam. If it constructs a client internally, consider adding an optional parameter whose default retains the existing client. Preserve the production path during this edit. Check positional callers, initialization and error handling before deciding that adding a parameter preserves behavior.

The query substitute returns a small, explicit data set. A test destination captures the CSV and records the number of delivery attempts. Fix the reference date. You can now exercise the transformation without a database, network access or credentials. Keep the actual selection and formatting implementation: substituting those too would remove the evidence you were seeking.

Use the following cases. Their outcomes are expectations for this exercise; a real project still needs domain validation.

Make specific comparisons for important fields. When the contract requires exact bytes, also check separators, encoding and line endings. Avoid normalizing the CSV until the test ignores a difference that matters to its consumer. Removing a volatile timestamp from a comparison may require a separate check of its format.

For a concrete comparison, fix the date at 2026-10-01 and use three charges due on 2026-09-30, in this order: F01, active, 1,099 cents; F02, canceled, 250 cents; F03, active, 901 cents. Suppose the controlled run before the fix produces the CSV below, using ; and calling the destination once. This is a hypothetical baseline for the exercise; in a project, obtain it from the existing implementation.

invoice_id;amount_cents
F01;1099
F02;250
F03;901

After the fix, the expected output retains the header and rows F01;1099 and F03;901, in that order, with one destination call. The old baseline includes F02; the new expectation excludes it through an explicit business decision. Integer amounts avoid adding a rounding convention to this example. If the system calculates fractional amounts, add a separate case recording its actual rounding rule.

Then change the business rule. The canceled-charge case fails before the fix and passes afterward; other cases should retain their expectations. A reviewer can distinguish preparation for testing from the functional change. This separation helps locate regressions and revert the fix without discarding all the newly created visibility.

Breaking the first dependency introduces risk too

There is a circular difficulty here: changing code is necessary before testing it. The book is particularly useful for addressing this imperfect starting point. A practical response requires restraint. A small mechanical edit with careful inspection offers a smaller review surface than reorganizing the whole class before writing the first test.

In the exercise, exposing client construction while preserving its default differs from replacing the entire data layer with repository abstractions. The latter might become worthwhile later. Right now, it adds decisions about interfaces, failures and transactions to a diff whose purpose is discovering existing behavior.

Do not describe preparation as proven safe when tests do not exist yet. Record what was inspected, run available checks and request review from someone familiar with the affected path. If a controlled full-flow execution is available, compare its output before and after. That evidence still covers only the exercised cases.

Where the confidence stops

An in-memory query test checks what the routine does with received records. It does not establish that SQL retrieves the right records, respects isolation or converts values correctly. Keep an adapter integration test with controlled data and a database compatible with the real environment.

A captured destination does not establish that the provider accepts the file. Format, authentication and error responses need their own checks. Retrying delivery after a timeout may duplicate effects even when every local test passes. That risk requires an idempotency contract or reconciliation, depending on the system.

Line coverage cannot measure this gap. I prefer a test that detects an incorrectly included charge to dozens of expectations about internal calls. Ask which incorrect edit would make the suite fail. If changing a charge's status never affects the result, investigate the assertion's usefulness before increasing coverage.

What has aged and what deserves criticism

Examples and manual techniques reflect the edition's languages and tools. A TypeScript or Python developer must translate the intent of approaches based on compilation, linking or inheritance. Copying their form literally may create something more complicated than an explicit substitution already available in the language.

Temporary seams can also become permanent clutter. A parameter introduced for a test may accidentally become part of an API; a test subclass may depend excessively on internal structure. After establishing protection, consider consolidating the separation and removing mechanisms that have stopped serving a purpose. Testability must coexist with understandable production code.

The book offers techniques rather than an automatic risk estimate. A handful of inputs leaves plenty unknown. Readers seeking a complete approach to data migration, concurrency or replacing a distributed system will need other material. Passing some tests creates no obligation to preserve an unworkable design forever.

Who should read it and what belongs alongside it

I recommend it to developers who know basic testing and maintain code that is difficult to instantiate or execute. Less experienced developers can benefit with review from someone who knows the system. Without a grounding in dependencies and external effects, first practice testing functions and small objects.

Within this series, Refactoring helps select structural moves once protection exists. TDD by Example develops new behavior through expectations. Clean Code supports discussions of readability. Feathers tackles an earlier question: how can this code run without dragging its surroundings into the test?

Postpone this book if you want a first introduction to programming. If your immediate challenge is a new rule in a well-tested module, TDD or Refactoring may offer a faster payoff. The reading investment makes sense when reaching the code with enough control to change it is the obstacle.

A reading plan and verdict

Choose a small correction from your backlog. Read about seams and locate the chapter matching your obstacle. Write down which behavior should change, which must remain and who can validate the distinction. Separate structural preparation from the functional fix during review.

The exercise is complete when someone else can run the cases without external services, explain each expectation and identify contracts still requiring integration checks. After delivery, try a second nearby change. It should reuse some protection; rebuilding everything suggests the entry point is too narrow or tightly coupled.

I strongly recommend this book for maintenance under uncertainty. Its practical reward is learning to produce evidence where previously there was only inspection and apprehension. Apply techniques to the code that needs changing, acknowledge the tests' reach and use the resulting confidence to improve the design in reviewable steps.