TDD in Legacy Code - ATDD for System API Redesign
When the development team decides to redesign the API, teams have the risk of introducing regression bugs. How should we implement a API Redesign in a safe way?
🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.
API Redesign is risky without tests
API Redesign (in the case of public-facing APIs) is risky because it could cause regression bugs.
How to use ATDD for API Redesign
When implementing User Stories, applying ATDD involved writing a failing Acceptance Test to specify the behavior, implementing the behavior, and verifying that the Acceptance Test passes. A similar process happened with implementing Bug fixes, since both User Stories & Bugs are concerned with behavioral changes.
But how do we handle structural changes - such as API Redesign? Example, for splitting one field (e.g. “name“) into two fields (“first name“ and “last name“). It’s just a structural change, not a behavioral change.
How ATDD differs:
For behavioral changes, applying ATDD meant that we start with writing a failing Acceptance Test.
Regarding structural changes (System API Redesign), we do NOT write an Acceptance Test. Instead, we update the System API Driver to reflect the updated API, which causes multiple Acceptance Tests to fail.
Let’s illustrate the ATDD cycle for System API Redesign Tasks:
Here are the steps to introduce ATDD for API Redesign in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️