> For the complete documentation index, see [llms.txt](https://docs.visdom.virtuslab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.visdom.virtuslab.com/visdom-testing/contract-tests.md). # Contract tests In a system split across services, the interesting bugs live at the seams. A field is renamed and the consumer breaks. An optional field becomes required and three downstream services fail quietly. A new enum value arrives and everything that switches on it falls over. The usual answer is to deploy several services together and test them end to end. That works and it is slow, brittle and expensive: minutes to stand up, one flaky dependency away from a red build for reasons unrelated to the change. Contract testing verifies that services still fit without running them together. Each side tests against a **contract**: a written statement of what a consumer needs and what a provider promises. If the contracts agree, the services agree. ## Consumer-driven, not provider-dictated The consumer declares what it actually uses, and the provider proves it still satisfies that. This inverts the usual direction, and the inversion is the point: a provider learns which of its fields anybody depends on, rather than guessing, and can change everything else freely. Contracts are published centrally and verified against real provider versions. Before a deployment, the question "is every contract I am party to verified against the version going out?" has a yes-or-no answer, which is what makes a release decision mechanical rather than a matter of nerve. ## Why an agent makes this urgent An agent changing a service has no memory of who consumes it and no fear of breaking a team it has never met. It sees a response shape and treats it as private. Contracts are what tell it, in the only language it respects, that the shape is a promise. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.visdom.virtuslab.com/visdom-testing/contract-tests.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.