TDD in Legacy Code - Maintainable External System Contract Tests

Directly referencing the HTTP Client in our External System Contract Tests? This makes the tests very hard to maintain. That's why we need to use Drivers as an abstraction layer.

🔒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:

---

Coupling Contract Tests to HTTP Clients

When introducing External System Contract into Legacy Code, the most straightforward way is to directly call the HTTP client from the test.

What if the External System changes? Nightmare

The problem with that approach is that we have External System URLs scattered around everywhere across the tests! If for whatever reason, some endpoint changes on the External System, we may need to update several tests! Or even worse, if we switch from one External System Provider to another, we’d probably need to completely rewrite all the contract tests.

How to write maintainable Contract Tests?

That’s why we need Contract Tests for External Systems which can 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 refactor External System Contract Tests in Legacy Code to be more maintainable. I’ll provide you with step-by-step guidance on how to refactor them in your GitHub Sandbox Project. ⬇️⬇️⬇️