TDD in Legacy Code - Contract Tests - Components
How can Frontend & Backend Teams find out that they can't communicate, instead of waiting for slower Acceptance Tests?
📅 Join me: Clean Architecture for Backend Developers on Wed 26th Aug, 5:00 - 6:30 PM (CEST)
🔒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.
Component Tests are fast because they stub their dependencies
Component Tests give us fast feedback by testing a component in isolation.
The Frontend Team stubs out the Backend in Frontend Component Tests in Legacy Code; the Backend Team stubs out the External System (the ERP) in Backend Component Tests in Legacy Code.
But your stubs might be wrong!
When the Frontend stubs the Backend, it makes an assumption: “POST /api/orders returns 201 with { orderNumber }.”
But what if the Backend Team renames that field, or changes the status code, or moves the endpoint. What happens to the Frontend’s Component Tests?
They stay green. They’re still testing against the stub which hadn’t changed — but the stub’s assumption is now wrong.
The bug doesn’t show up until the Frontend and the Backend actually run together — when the Acceptance Test fails.
How to catch stub mismatch? Contract Tests
The Frontend says:
“This is what I expect from the Backend.”
Pact turns that expectation into a contract.
The Backend then runs the contract against itself.
If the Backend no longer matches what the Frontend expects, the Backend build fails.
You don’t write a new test from scratch. You take a Frontend Component Test you already have, and replace the stub with a contract.
Here are the steps to introduce Contract Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️