TDD in Legacy Code - Component Tests - Frontend
ATDD provides business-facing feedback, but the feedback loop is too long. That's why we need CTDD, which requires us to write Component Tests. Let's start with the Frontend.
📅 Join me at the FREE live event Stop Breaking Production: ATDD in Legacy Code (Sep 24 at 5:00 PM CET)
🔒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.
ATDD provides business-facing feedback.
Through our journey up to now in TDD in Legacy Code series, we’ve introduced ATDD. We received major benefits from ATDD:
We reached alignment between PO, Software Engineers & QA Engineers, so that they have a shared understanding of requirements before Software Engineers start coding
Acceptance Tests provide us with an objective “Definition of Done“ for User Stories & Bug Tickets, and provide us with a real measure of progress
Software Engineers receive relatively fast feedback whether they satisfied Acceptance Criteria or whether they introduced Regression Bugs, they wait for the Pipeline’s Acceptance Stage (1hr) rather than waiting for Manual QA Engineers (days/weeks)
QA Engineers are able to bring much higher value to the team, (1) by contributing to team discussions to ensure good scenario coverage, as reflected in writing testable acceptance criteria, and (2) by being able to focus more on Exploratory Testing, Usability Testing (instead of repetitive Regression Testing)
All the above, combined, means that we are able to deliver software safely & quickly.
But the ATDD feedback loop is too long.
ATDD is excellent in providing us with business-facing feedback (did we satisfy requirements, or did we introduce regression bugs). However, we face the following issues due to the slow feedback loop:
It takes a long time to get feedback for a new Acceptance Test. It may take several hours/days for all teams to finish their work, associated with making some Acceptance Test pass, e.g., the Frontend Team needed to make changes, and the Backend Team needed to make their changes. We have to wait for everyone to finish, and then we’re able to see the results of the Acceptance Test. This is a slow feedback loop (we had to wait hours/days).
If the Acceptance Test fails, we have no idea which team is at fault - is the problem with Frontend, or with the Backend? Or perhaps is there a problem of miscommunication between them, that their API expectations aren’t matching? So we have to do time-consuming troubleshooting, involving multiple teams.
When we fix regression bugs (because some Acceptance Tests failed), we have to wait for 1hr for the Acceptance Stage to finish, so that we can be sure that our fix is correct and that we didn’t break anything. Similarly, when we do some refactoring, we have to we have to wait for 1hr for the Acceptance Stage to finish, so that we can be sure that our refactoring hasn’t broken anything. Suppose some Acceptance Test(s) fail. We don’t know whether our commit caused the failure or some other interim commit from another team member caused the failure, so we may need to manually review/debug multiple commits to discover which commit(s) caused Acceptance Tests to fail.
That’s why we need CTDD.
How to overcome the problems of ATDD?
We need an additional inner loop - Component Test Driven Development (CTDD). This means that each team internally would be able to specify (RED), implement & verify (GREEN), and refactor (REFACTOR) their component, independently of other components. The benefits are:
Our team doesn’t have to wait several hours/days for all other teams to complete their work for an Acceptance Test, but rather we get feedback in minutes whether our Component Test(s) associated with that Acceptance Test are passing, so we have assurance that our work is completed.
Our team doesn’t have to wait for a failing Acceptance Test to discover that we’ve introduced a bug. Instead, we’d most likely discover it through the Component Test. We can do troubleshooting within their team, no need to involve other teams.
When we fix a regression bug caused by our Component, or when we do refactoring, we can get fast feedback (minutes) whether or not the Component works correctly.
We need Component Tests to practice CTDD.
A key skill in practicing CTDD is the ability to write Component Tests. That is why we first need to write some Component Tests last to gain practice, before we move on to CTDD.
In this article, we’ll show how to write Component Tests. Firstly, we’ll show Frontend Component Tests, and later we’ll also show Backend Component Tests.
Here are the steps to introduce Frontend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️