A Cypress test that borrows the last copy of a book passes, then fails on every retry. Why?

## What a Cypress retry actually repeats When `retries` allows another attempt, Cypress re-runs the **test**, not the run and not the spec. An attempt consists of: - every Mocha `beforeEach` hook that applies to the test, in declaration order; - the `it` body, from its first command; - every Mocha `afterEach` hook, once the attempt ends. Everything else stays as it was. Mocha's `before` and `after` hooks belong to the suite and run once; a failure *inside* `before` or `after` does not even trigger a retry. Cypress resets the browser between attempts the way it does between tests, but the browser is the only thing it can reset. Your API, your database, your message queue and your seeded fixtures are all outside the runner's reach. ## Why the second attempt fails differently 1. Attempt one runs `before`, which seeds a catalogue with exactly one copy of the title. 2. The test clicks **Borrow**. The request succeeds; the loan row is committed on the server. 3. The assertion on the confirmation banner fails — say the banner renders late and the wrong selector was used. 4. Cypress starts attempt two. `beforeEach` runs, the page is reloaded, `before` does **not** run. 5. The catalogue now shows zero copies. The Borrow button is disabled, so the click fails actionability and the error is nothing like the one that started the retry. The retry has not given you a second chance at the same test; it has given you a first run of a different one. ## What retrying can and cannot cure | Failure cause | Cured by a test retry? | |---|---| | A render that arrived after the assertion first ran | Yes, usually | | A backend response that was unusually slow once | Yes, usually | | A wrong selector or a real regression | No — fails identically every attempt | | An effect the first attempt already committed | No — and the retry fails for a new reason | | A failure raised inside a `before` or `after` hook | No — such failures are never retried | ## Making a test survive its own retry - **Move consumable setup into `beforeEach`.** What a retry re-runs is the per-test hook, so seeding through `cy.task()` there gives every attempt its own data. - **Make setup idempotent or unique.** Seed a fresh title with a generated identifier per attempt rather than reusing one row that a failed attempt may already have consumed. - **Keep irreversible steps out of the middle of a long test.** The later a committed effect sits, the more of the test is unrepeatable after it. - **Read the retry's error, not just the first one.** A different error on attempt two is a strong signal that the test is state-dependent rather than merely slow. - **Use `Cypress.currentRetry` to recognise the situation**, not to paper over it: logging that a test is on attempt two is useful, weakening its assertions on attempt two is not. ## What `afterEach` can and cannot undo Because Mocha's `afterEach` runs at the end of **every** attempt, including the failed ones, it is the natural place for cleanup that makes the next attempt viable — returning the borrowed copy or deleting the loan row through `cy.task()`. Two limits matter before you lean on it: - A failure raised *inside* `afterEach` does not trigger a retry, and it is reported against the test, so fragile cleanup turns one problem into two. - Cleanup only helps where the effect already exists. A test that fails before it borrows anything and one that fails after it has borrowed leave different states behind, so the cleanup has to tolerate both without asserting. That asymmetry is the reason per-attempt seeding in `beforeEach` is usually the sturdier half of the pair: creating what this attempt needs is unconditional, while undoing what a previous attempt may or may not have done is guesswork. ## When the honest answer is "do not retry this test" Some tests consume something that cannot be recreated inside the attempt: a one-time token, a limited stock item, an external sandbox with a shared identity. For those, a retry is not a neutral safety net — it converts one honest failure into a second, misleading one, and it costs a full test run of wall-clock time to do it. Setting `retries` low or zero for that specification, and fixing the underlying seam so setup can repeat, is a better trade than a count that hides the first failure behind a second.