TDD in Legacy Code - ATDD for External System API Changes
When the External System API is changed, our System stops working. How should we safely adapt our System to the changed External System API?
🔒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.
Adapting to External System API Changes is risky without tests
Suppose that the External System API has changed. But we don’t have any External System Contract Tests. It means we’d find out our System is broken when users start reporting Production Bugs. We’d then have to wait for the slow-running Manual QA Testing to reproduce those bugs, and then discover - it’s due to External Systems!
So now that we have to adapt our System, we’re faced with additional challenges - our Legacy Project doesn’t have tests, and the business logic is often coupled to communication with External Systems. Thus, when an External System changes its API, if we try to adapt to the updated External System API, we may need to make broad changes, and it’s very risky… when there’s no tests.
How to use ATDD for handling External System API Changes
When implementing User Stories, applying ATDD involves 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 External System API changes, e.g. there might be a change in their URL routes, or changes to the data input/output structures. It’s just a structural change, not a behavioral change.
How ATDD differs:
For behavioral changes, applying ATDD means that we start with writing a failing Acceptance Test, then we try to implement the System to make the test pass.
Regarding structural changes (External System API Change), we do NOT write an Acceptance Test. Instead, we update the External System API Driver to reflect the updated API, which causes multiple Acceptance Tests to fail. Then we try to “adapt“ our System so that the Acceptance Tests can pass again.
Let’s illustrate the ATDD cycle for External System API Change Tasks:
Here are the steps to introduce ATDD for External System Changes in Legacy Code. I’ll provide you with step-by-step guidance on how to handle External System Changes in your GitHub Sandbox Project. ⬇️⬇️⬇️