> 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/choosing-a-shape.md). # Choosing a shape There is no single correct distribution of tests. The right shape follows the architecture, and picking the wrong one is how teams end up with a suite that is both slow and unconvincing. | Shape | Weight sits in | Fits | | ------------- | ------------------------------------------------------ | ----------------------------------------------------------------- | | **Pyramid** | Many unit tests, fewer integration, minimal end-to-end | Monoliths and libraries, where most logic is reachable in-process | | **Trophy** | Integration | Modern front ends, where the interesting behaviour is composition | | **Honeycomb** | Contracts between services, thin unit layer | Microservices, where the seams are the risk | | **Diamond** | A wide integration layer | Domain services with heavy orchestration | The layers in this section are not a replacement for that choice. They are what makes whichever shape you pick resistant to a code author who also writes the tests. ## What to measure Four questions are worth answering continuously, and none of them is coverage: * Does the behaviour hold on inputs nobody wrote down? * Would the tests fail if the code were wrong? * Did the change respect the architecture? * Do the services still fit together? ## A suite nobody trusts is not a gate One number decides whether any of this works: how often a failing test means a real defect. When most failures are noise, people stop reading them, and an agent asked to make the build green will happily "fix" a flaky test by deleting the assertion. So flakiness is treated as a first-class defect. Unreliable tests are quarantined, excluded from the signal given to agents, and repaired rather than tolerated. A suite that fails for real reasons is what turns every other layer here from a report into a gate. --- # 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/choosing-a-shape.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.