Reliability and CI

Finish the testing strategy

Create a maintainable suite with clear ownership, documented commands, deliberate gaps, and a process for fixing flaky tests.

8 minute lesson

~~~

A suite is a product that needs maintenance. Slow, duplicated, ownerless tests eventually become ignored tests.

Document each test layer, local and CI commands, required services, data isolation, and failure artifacts. When a test flakes, record and fix the cause or quarantine it visibly with an owner and deadline; do not silently retry forever.

Turn the course into a risk matrix rather than a folder inventory. Useful columns are risk, observable evidence, real boundary, test location, runtime, owner, and known gap. For example, “duplicate ISBN cannot overwrite a book” needs database constraint evidence; “reader can add a book” needs visible browser evidence. The matrix exposes duplicated tests that cross the same boundary and important risks that no test owns.

Map changes to feedback. A validation edit should get immediate unit results and the relevant HTTP contract tests. A migration edit must run clean-install, supported-upgrade, and repository tests. A shared UI change should run the critical browser journeys. The full suite still runs before release, but developers should not wait for every browser and performance test to learn that a pure function is wrong.

Define a flaky-test policy before flakiness becomes normal. Record the first failure’s trace and environment, assign an owner, and fix shared state, timing, or infrastructure. If quarantine is necessary, keep it visible with a reason and expiry date. Retries may collect evidence, but an eventually green result does not erase the first failure.

Review the suite by asking what each test uniquely proves. Delete tests that duplicate stronger evidence without providing faster diagnosis. Keep deliberate gaps explicit: exhaustive browser validation may be too expensive when unit and HTTP tests already protect the rule.

Write the Books app test matrix from pure validation through API, database, browser, and k6 smoke coverage. Mark one intentional gap, one duplicated test to remove, and one failure artifact each layer must retain. Then give every flaky or quarantined test an owner and review date.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →