TDD in Legacy Code - Maintainable Acceptance Tests
Acceptance Tests might be coupled to External System Stubs, which makes them expensive to read, and fragile when External System interface changes. So we need to introduce an abstraction layer - DSL.
🔒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. To get these articles in your inbox every week, subscribe:
Problem: Coupling to External Systems Stubs
In Legacy Code, we migrated E2E Tests to Acceptance Tests. The key aspect we introduced there was the setup of External System Stubs, e.g. using WireMock where we could stub out the endpoints, the requests and the responses.
The problem is that the test was directly coupled to the External System Stub!
Acceptance Tests become hard to maintain!
This coupling poses two maintenance problems:
As we read the Acceptance tests, even though access to the System is readable (because it’s expressed using DSL), access to External Systems is hard to read because of direct reference to the External System endpoints
If there’s changes to any External Systems, e.g. endpoint name change, or change in request/response data structure, or if we switch from one External System provider to another one, it would cause many Acceptance Tests to fail, and we may need to update hundreds of Acceptance Tests
To summarize, the increased cost of maintenance occurs because:
These Acceptance Tests are hard to read. Due to direct coupling to External System interfaces, only developers can write/maintain such Acceptance Tests, it can’t be done by the QA Engineer.
Many tests would need to be updated if there’s a change in the External System interface
How to write maintainable Acceptance Tests?
Just like access to the System in Acceptance Tests is maintainable, we want access to External System Stubs in Acceptance Tests to also be maintainable. Then, the Acceptance Tests would be easy to read & write, could be written by anyone (e.g. QA Engineers & POs, not just developers). Furthermore, if the External System API changes, we’d be able to fix it in one place, rather than having to fix hundreds of failing tests.
We’ll apply Dave Farley’s Four Layer model to External System Stubs and introduce an abstraction layer between Acceptance Tests and External System Stubs.
Here are the steps to refactor Acceptance Tests in Legacy Code, to ensure that they’re more maintainable. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️