Acceptance Tests
Acceptance Tests verify System behavior in isolation from External Systems, thereby enabling us to test any functional Acceptance Criteria, thus overcoming the limitations of E2E 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:
What are Acceptance Tests?
We use Acceptance Tests to verify the behavior of the System. We can execute any scenario.
Acceptance Tests target the System, and they span the System and External System Stubs.
What’s the similarity between Acceptance Tests and E2E Tests? They both verify System Behavior from the End User perspective.
What’s the difference between Acceptance Tests and E2E Tests? Acceptance Tests target the System connected to the External System Stubs. E2E Tests target the System connected to the External System Test Instances.
The biggest advantage of Acceptance Tests is that we can test any functional Acceptance Criteria (this is not possible with E2E tests).
Acceptance Tests target the System, and they span the System and External System Stubs. Acceptance Tests differ from E2E Tests because Acceptance Tests span External System Stubs unlike E2E Tests which span External System Test Instances. Acceptance Tests are executed on the Acceptance Environment.
Due to the usage of External System Stubs, we have full control. Therefore, we can test ANY Acceptance Criteria with the Acceptance Tests (this wasn’t possible with E2E Tests).
If the System exposes a UI (for End Users), the Acceptance Test can use a Web Driver to run commands on the UI, and to do verifications via the UI. The External Systems are stubbed out:
If the System exposes a REST API (so that other systems can connect to it), the Acceptance Test can use a HTTP Client to connect to the System’s REST API, and do verifications via the REST API. The External Systems are stubbed out:
If the System exposes both a UI and a REST API, then we combine the above:
The above diagrams illustrate the simplest possible way to write Acceptance Tests. However, to ensure better maintainability, I recommend the Four Layer Model.
Why Acceptance Tests?
E2E Tests provide the highest level of realism for End User Testing, but they come with the following limitations:
Primary Problem: E2E Tests can NOT test all the functional Acceptance Criteria. Thus, E2E Tests don’t provide us feedback on whether a User Story is functioning correctly.
Secondary Problem: E2E Tests can NOT isolate faults between our System versus External Systems. When an E2E Test fails, the issue could be in our System and/or External Systems.
That’s why we need Acceptance Tests: ⬇️⬇️⬇️