TDD in Legacy Code - Acceptance Testable Architecture
Legacy Code is often statically coupled to External Systems, making it impossible to write Acceptance Tests. That's why we need Acceptance Testable Architecture.
🔒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:
Legacy Code might not be Acceptance Testable
Legacy Code might have the following problem - it might be statically coupled to External Systems:
Hard-coded connections to External HTTP APIs
Static calls to the System Clock and static calls to other sources of non-determinism
Static calls to complex external libraries, where the input-output mapping of the external library is beyond our knowledge
We can’t introduce Acceptance Tests
In order to write Acceptance Tests, we need to have External System Stubs. This enables us to fully test any Acceptance Criteria relating to our System, by targeting our System and setting up the External System Stubs.
However, in order to be able to communicate with the External System Stubs, we’d need to ensure External System Configurability.
So we need to ensure Acceptance Testable Architecture
That’s why we need to do some changes to our source code to ensure External System Configurability.
But how do these changes… without risking the whole system?
Here are the steps for achieving E2E Testable Architecture in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. I’ll review & provide feedback in the comments: ⬇️⬇️⬇️
