TDD in Legacy Code - Maintainable Component Tests - Frontend
Many Frontend Teams write unmaintainable Frontend Component Tests - coupled to the UI. These tests are brittle. I'll show you how to refactor these tests to be maintainable, by using DSL & Drivers.
📅 Join me for Acceptance Testing (Live Training) on Wed 25th Feb (17:00 - 19:00 CET) (100% discount for Optivem Journal members)
🔒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.
Frontend Component Tests provide fast feedback
We’ve seen in the previous article, Frontend Component Tests in Legacy Code, that Frontend Component Tests can provide us with fast feedback. The Frontend Team can test Frontend in isolation, by stubbing out the Backend.
But they can be a maintenance nightmare!
In Frontend Component Tests in Legacy Code, we illustrated the “simplest“ Frontend Component Tests. But unfortunately, they are unmaintainable.
The simplest way to write a Frontend Component Test is to locate UI elements via Text, Role, ID, etc., then trigger some actions on those UI elements. For example: (pseudocode)
const skuInput = screen.getByLabelText('SKU');
fireEvent.change(skuInput, { target: { value: 'APPLE1001' } });The problem with these kinds of tests, is that if there is UX/UI Redesign, or some UI refactoring, that many such tests may break, so we have to waste time fixing tests.
How to write maintainable Frontend Component Tests?
In this article, I’ll show you how to introduce layers of abstraction, i.e. Component Test Architecture, so that you spend much less time writing & maintaining these tests.
Here are the steps to introduce Maintainable Frontend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️