11 Coping with legacy
This chapter covers
- Why simply using Gherkin for test automation is not BDD
- Choosing which legacy functionality to document using Gherkin
- What to do with existing manual test scripts
The WIMP team is adopting BDD partway through delivery of their product. The code that has already been written can be thought of as legacy code. If we use Michael Feather’s definition of legacy code, “legacy code is code without tests”, then the majority of code that exists is legacy code. Therefore, most software professionals spend much of their career working with legacy code. Teams that find a way to adopt BDD practices while working with legacy code will find that the benefits are significant.
In this chapter we look at how BDD practices can help when working with legacy code. There’s a lot more about legacy code that remains out of scope for this book.
11.1 BDD on legacy projects
In Chapter 7, “Cleaning up an old scenario” we saw the team reverse engineer the behavior of the code using example mapping, which is a technique that we typically use during discovery. They went on to formulate illustrative scenarios from the concrete examples in the example map. The knowledge recovered during this process will help both now and in the future. For now, it helps developers verify that changes they make to the code have not broken the system. In the future, it will enable any stakeholder to confidently determine the current behavior of the system.