Writing Tests That Catch Real Bugs

Read before you buy: the PDF here is a free sample — the first 20 pages of the 435-page book (payments, sales and reviews on this demo site are sample data). Get the full e-book at thenexbooks on Gumroad.

Almost every team says it values unit testing. Far fewer have a suite they would bet a Friday deploy on.

The gap is not knowledge of a framework — frameworks are small and their documentation is good. The gap is judgment: knowing what deserves a test, what a test should assert, where to put the boundary between the code under test and everything else, and how to tell a suite that protects you from a suite that merely runs green.

This book teaches that judgment, on one realistic system. Coppervane is a subscription billing and usage-metering platform: proration across a 28-day month, graduated pricing tiers, a percentage discount that has to round across invoice lines without losing a cent, a trial ending on the day the plan changes. Around those rules sit a database, a payment provider, a clock, a stream of usage events, and a 1,900-line legacy engine nobody will touch — which Chapters 23 to 28 rescue.

It is also honest about the costs. Tests are code you maintain, and a badly designed suite is worse than no suite. Several chapters are about deleting tests, merging them, or deciding not to write one.

• 435 pages · 28 chapters + 4 appendices
• A precise definition of the unit under test, and why "unit = class" produces the worst suites
• Choosing what to test by risk — and a clear list of what not to test at all
• Names, structure, and assertions that turn a failure message into a diagnosis
• Parameterized cases and property-based testing for the input space you cannot enumerate
• Builders and object mothers that keep test data readable at scale
• The five test doubles, when each is right, and the design changes that make most unnecessary
• Seams, dependency injection, and the pure core / imperative shell split, applied step by step
• Mocking frameworks in full — then a worked rewrite of an over-mocked test into fakes
• Controlling time, randomness, ids, ordering, locale, and everything else that causes flakes
• Honest positions on testing database code and code that calls someone else's service
• What coverage hides, and mutation testing as a way to grade the tests themselves
• TDD on a real ticket over eight cycles — including where TDD does not fit
• Making a slow suite fast and a flaky suite deterministic, with a diagnosis procedure for both
• Getting legacy code under test: seams, characterization tests, golden masters, safe refactoring
• CI gates, review practice, an anti-pattern catalog, and a full closing case study
• No benchmarks, defect-rate statistics, or productivity claims — every number is the system's own

Table Of Contents

Part I — Foundations

• Ch 1 · What a Unit Test Is — and What It Is Not
• Ch 2 · Why Test Suites Fail: Brittleness, Flakiness, and False Confidence
• Ch 3 · The Anatomy of a Good Test
• Ch 4 · Meet Coppervane: The System We Will Test
• Ch 5 · Setting Up: Runner, Assertions, Doubles, and a Fast Feedback Loop

Part II — Writing Tests Worth Keeping

• Ch 6 · Naming and Structure: Tests as Executable Documentation
• Ch 7 · Choosing What to Test: Behavior, Not Implementation
• Ch 8 · Assertions: Precision, Failure Messages, and Custom Matchers
• Ch 9 · Parameterized Tests and Property-Based Testing
• Ch 10 · Test Data: Builders, Object Mothers, and Fixtures
• Ch 11 · Errors, Edge Cases, and the Boundaries Nobody Tests

Part III — Dependencies and Boundaries

• Ch 12 · Test Doubles: Stubs, Mocks, Fakes, and Spies
• Ch 13 · Designing for Testability: Seams, Injection, and a Pure Core
• Ch 14 · Mocking Frameworks — and When to Put Them Down
• Ch 15 · Time, Randomness, and Everything Else That Is Not Deterministic
• Ch 16 · Testing Code That Owns a Database
• Ch 17 · Testing Code That Calls Someone Else's Service

Part IV — Coverage, Quality, and Feedback

• Ch 18 · Coverage: What It Measures and What It Hides
• Ch 19 · Mutation Testing: Grading the Tests Themselves
• Ch 20 · Test-Driven Development on Real Work
• Ch 21 · Keeping the Suite Fast
• Ch 22 · Flaky Tests: Diagnosis, Cure, and Prevention

Part V — Legacy Code and Refactoring

• Ch 23 · Getting Legacy Code Under Test
• Ch 24 · Characterization Tests and Safe Refactoring
• Ch 25 · Refactoring the Tests: Removing Duplication Without Hiding Intent

Part VI — Team, Pipeline, and Practice

• Ch 26 · Tests in the Pipeline: CI, Reports, and Required Checks
• Ch 27 · Team Practice: Review, Ownership, Conventions, and Anti-Patterns
• Ch 28 · Case Study: Rewriting Coppervane's Billing Engine

Appendices

• App A · Testing Pattern Cheat Sheet
• App B · Templates and the Same Tests in Five Languages
• App C · Test Suite Health Checklist
• App D · Glossary

WHO IT IS FOR
Developers who write tests but suspect they are testing the wrong things. Senior engineers and tech leads who review tests, set conventions, and have to defend what the suite costs. Engineers inheriting a codebase with no seams and no tests. Teams fighting a slow or flaky suite that has quietly stopped being trusted. You should be comfortable in one object-oriented or statically typed language and know what an interface is. No prior experience with mocking frameworks, TDD, or coverage tooling is assumed.

A NOTE ON LANGUAGES
The code is Java 21 with JUnit 5, AssertJ, and Mockito, because that stack makes every concept in the book expressible and its idioms are widely imitated elsewhere. The techniques are not specific to it. Appendix B writes the book's core tests four more times — in pytest, Vitest, Go's testing package, and xUnit.net — with a concept-by-concept translation table, and the text calls out where a language's idiom differs materially.

FORMAT
PDF (A4), 435 pages, English, clickable table of contents and PDF bookmarks. 1st Edition, 2026. Published by thenexbooks.

A NOTE ON NUMBERS
This book contains no benchmarks, defect-rate statistics, productivity figures, or survey results. Those depend on codebase, team, and measurement method to the point where quoting them is misleading. Where a number appears, it is Coppervane's own money and quantities, arithmetic worked out in front of you, or a blank to fill in from your own measurements. This book is independent and is not affiliated with or endorsed by any of the projects or vendors it names.

Book details