TDD in Legacy Code - Maintainable E2E Tests

E2E Tests are often coupled to the UI, many tests can easily break due to minor visual changes. This makes them very expensive to maintain. We need to refactor them with Layered Model.

🔒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 often has E2E Tests coupled to the UI

When we introduced E2E Tests into Legacy Code, we wrote the tests directly using a WebDriver, and then redesigned them to use the Page Object Model.

These E2E Tests are hard to maintain

In both cases, the tests are hard to maintain - in the POM Model, the tests are directly coupled to the UI structure.

We need to adopt a maintainable E2E Design

Let’s see how to introduce maintainability and make the E2E Tests more readable and decoupled from the System implementation. Even as the System API changes (due to UI changes and public REST API changes), if the behavior doesn’t change, our tests remain stable and only a small percentage of plumbing is affected:

Previously, we introduced:

• E2E Tests - WebDriver Model

• E2E Tests - POM Model

Now let’s refactor towards:

• E2E Tests - DSL-POM Model

• E2E Tests - Four Layer Model

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