TDD in Legacy Code - E2E Testable Architecture

Legacy Code might be so tangled up that it might not even be E2E Testable, which prevents us from introducing E2E Tests and Acceptance Tests. We need an E2E 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 E2E Testable

Legacy projects might have the following problems:

• Hard-coded connection strings to Production Instances of External Systems → this is dangerous because we can change the state of Production Instances during testing

• External Systems might still be in development → we might need to wait months for months for the External Team to release a Test Instance so that we can test our integration with them

Then we can’t introduce automated E2E Tests

In those cases, we can’t introduce E2E Tests at all, because we want to be able to run E2E Tests safely, at any time, no constraints, and independently of the development status of other teams. (This problem applies not only to E2E tests, but also to Smoke Tests)

We need to ensure E2E Testable Architecture

Often developers try to introduce just Unit Testability (a lot of techniques in Working Effectively with Legacy Code help you untangle messy code to make it Unit Testable).

The problem is, based on my experience, it’s too much to try to jump to Unit Testability. That’s why I start with E2E Testable Architecture, then Acceptance Testable Architecture, then Component Testable Architecture, and finally, last but not least, to Unit Testable Architecture.

Is your architecture E2E Testable? If not, you need to re-architect it to support testability.

Here are the steps for achieving E2E Testable Architecture in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️