TDD in Legacy Code - External System Contract Tests

Acceptance Tests rely on External System Stubs. But how to we know that those Stubs are actually valid? We can only know if we have External System Contract 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:

---

Acceptance Tests rely on External System Stubs

In Acceptance Tests, we stub out External Systems, rather than connecting with the real External Systems, in order to test our System in isolation. By using Stubs, we have full control - we can translate any functional Acceptance Criteria into Acceptance Tests, which is a big benefit compared to E2E Tests.

But what if the External System Stubs are wrong?!

Suppose that we incorrectly stub out External Systems - perhaps we made an accidental spelling mistake in an endpoint. If that same “mistake“ is also in our System source code, the Acceptance Test will pass, even though the Stub is wrong!

The passing Acceptance Test gives us a false sense of security - this is very dangerous!

How can we ensure that the Stubs are valid?

We need Contract Tests for External Systems which will be executed both against the External System Stubs and against the External System Test Instances.

I’ll show you how to add Contract Tests to provide assurance that the External System Stub Drivers are actually valid.

Here are the steps to introduce External System Contract Tests in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce them in your GitHub Sandbox Project. I’ll review & provide feedback in the comments: ⬇️⬇️⬇️