isolated-testing-stylelisted

# Isolated testing style An opinionated way of writing tests. The examples are TypeScript and vitest, but the rules are about test design and hold for any framework. Each rule exists because of a specific failure it would have caught. ## Start with Given, When, Then Write the three comments before the test body, and before the code they will drive. ```typescript it("refuses an order once the offer has closed", async () => { // Given an offer that closed while the customer was on the page. // When the order is placed against it. // Then it is refused rather than accepted late. }); ``` Starting at this point, and not drifting to it, does three things. **It lowers the cost of starting.** You only have to say what the situation is, what happens, and what should result. That is a smaller question than "how do I test this?", and you can usually answer it before you can answer the bigger one. **It designs the interface.** Filling in `// When` forces you to name the single action under test, in the caller's vocabulary. A step you cannot write as one `// When` usually means the interface is wrong. **It keeps the test readable as documentation.** Tests are read far more often than they are written, and without the structure it is easy to produce a body where essential behaviour and incidental setup look alike. Then fill each comment in with the case it covers, and never with a restatement of the code: ```typescript it("refuses an order once the offer has closed", async