11 Coping with legacy

The chapter explains how BDD can be introduced into legacy codebases, where much of the software already exists without strong automated tests. In that setting, teams often need to recover knowledge about current behavior before they can improve or extend the system safely. The text emphasizes that this kind of reverse engineering can be useful, but it is not the same as true BDD, because BDD is about discovering and shaping behavior before implementation, not just documenting what is already there.

A key message is that teams should avoid treating Gherkin and Cucumber as synonyms for BDD. Using scenarios only to automate already-built functionality may provide some testing value, but it does not deliver the architectural and collaborative benefits of behavior-driven work. Because legacy systems were often built without failing scenarios guiding development, they are frequently more tightly coupled and harder to test at lower levels, which makes end-to-end automation tempting but expensive. Instead of documenting everything, the chapter recommends an incremental, risk-based approach that focuses on areas about to change, important business behaviors, or parts of the system that are most likely to evolve.

The chapter also cautions against blindly converting existing manual test scripts into automated scenarios. Manual scripts and illustrative scenarios serve different goals, so direct conversion often creates brittle documentation with high maintenance cost and little added insight. Some scripts may be useful as inspiration for identifying important behaviors or as prompts for conversations with testers and other experts, but each one should be evaluated on its own merits. Overall, the best use of legacy artifacts is to support understanding and selective documentation, while preserving the BDD principle that scenarios should clarify behavior and guide implementation rather than merely preserve old tests.