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. I’ll review & provide feedback in the comments: ⬇️⬇️⬇️