TDD in Legacy Code - Acceptance Stage

In Legacy Code, Acceptance Testing is often done manually, which makes ATDD impractical. Let's see how we can introduce the Acceptance Stage as an enabler for Acceptance Tests.

🔒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 has Manual Acceptance Testing

In Legacy Code, QA Engineers perform Manual Acceptance Testing (Manual E2E Testing), commonly referred to as UAT testing, before releasing the system to Production. This is time-consuming and error-prone, and results in delayed releases.

Can’t do ATDD with Manual Acceptance Tests

We can’t practice ATDD with Manual Acceptance Tests because they are time-consuming, hence were can’t run them often. Furthermore, they are error-prone, so we can’t trust their results.

We need an Acceptance Stage to support ATDD

In order to practice ATDD, we need to start development of any new feature with Automated Acceptance Tests, and to be able to regularly run those tests. We can run these Acceptance Tests to know when we’ve satisfied the User Story Acceptance Criteria. Furthermore, we use these tests in the future for regression testing at the system level. By eliminating manual acceptance testing, we gain both safety and speed, and enable QA Engineers to do Exploratory Testing.

Previously, we set up the Release Stage, which deployed Docker Images to environments, so that the QA Engineer could do Manual Acceptance Testing. In this article, we will be looking at the Acceptance Stage - running (Automated) Acceptance Tests, External System Contract Tests and E2E Tests.

Here are the steps for adding the Acceptance Stage to Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️