> 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/visdom-testing.md). # Visdom Testing Validation that holds when the same model wrote the code and the tests. When an AI writes the code and the tests, who tests the tests? A green build used to mean two independent things agreed: the implementation and the person who wrote the assertions. Generated code collapses that into one. The tests encode the same assumptions as the code, so they pass for the same reason the code is wrong. ## Four ways the usual signals break **Circular tests.** The test mirrors the implementation instead of the specification. It cannot fail for the reason you care about. **Metric inflation.** High line coverage with nothing meaningful asserted. Coverage measures what ran, not what was checked. **Architecture erosion.** An agent optimises for compiling and passing. The shortest path to that goal routinely cuts through a layer boundary the compiler cannot see. **API regression.** Models reach for what they saw most in training, which is old. Deprecated clients and retired patterns reappear in new code. ## What the component does about it It adds layers of validation an agent cannot satisfy by agreeing with itself, each answering a different question: * **Architecture tests**: does the change respect boundaries the compiler cannot see? * **Property-based tests**: does the behaviour hold across inputs nobody thought to write down? * **Mutation tests**: would the tests actually fail if the code were wrong? * **Contract tests**: do services still fit together, without standing them all up? None of them is new. What is new is the reason to insist on them: they are the checks that stay honest when the author of the code is also the author of the test. **Choosing a shape** covers where to put the weight, because the right mix depends on the architecture you actually have. --- # 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/visdom-testing.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.