A Cypress beforeEach hook throws: what happens to the rest of that suite?

## What Cypress does the moment a hook throws When a `beforeEach` fails, Cypress attributes the error to the **test the hook was running for**. That test is reported as **failed**, and the error carries an appended sentence naming the hook and the consequence, in the shape: > Because this error occurred during a `before each` hook we are skipping the remaining tests in the > current suite: `Borrowing flow` Then it stops running that block. The reasoning is blunt and correct: the hook would fail identically for every remaining test, so re-running it fourteen more times buys fourteen more copies of the same stack trace. If the hook was declared at the **root** of the spec rather than inside a `describe`, there is no enclosing suite to stop at, and the message says it is skipping all of the remaining tests instead. The same treatment applies to `before` and to `afterEach`. A failing `afterEach` is the one people find surprising: the test body may have passed, but the hook error still fails the test and takes the rest of the block with it. ## Three words that are not synonyms Cypress inherits Mocha's four statuses, and a report is unreadable if you blur the middle two. | Status | What it means | Typical cause | |---|---|---| | **passed** | ran to the end with no failing assertion | — | | **failed** | an assertion failed or a command errored | the defect, or a broken hook | | **pending** | Cypress was told not to run it | `it.skip()`, the `xit()` alias, an empty `it('title')` body | | **skipped** | Cypress meant to run it but could not | a `before`, `beforeEach` or `afterEach` failed | **Pending is a decision you made. Skipped is a consequence you did not choose.** A run that reports one failure and fourteen skipped tests has not told you that fourteen tests are fine; it has told you it never learned anything about them. Treat the skipped count as unknown coverage for that run, not as a clean bill of health. ## Reading the report A useful order of questions when a suite comes back mostly skipped: 1. **Find the failed test, not the first one alphabetically.** The failure is attributed to the test the hook was serving, so the named test is often perfectly healthy. 2. **Read the appended sentence.** It names which hook — `before all` or `before each` — and which suite title stopped. That tells you whether one block or the whole file went down. 3. **Look above the test in the Command Log.** The failing command sits in the hook's own section, not in the test body, which is why the test's commands look empty. 4. **Ask what the hook depends on.** A hook that visits a route, seeds the catalogue, or reads a fixture is depending on something outside the test, and that dependency is what broke. 5. **Check whether the skipped tests would even have passed.** They are unknowns; do not report the run as "one failing test". There is one extra wrinkle worth knowing: Cypress does not re-attempt a test when a `before all` or an `after all` hook fails, and the error says so explicitly when attempts were configured. A per-test retry cannot rescue a broken suite-level hook. ## Keeping a hook from taking the block down The fix is almost never "wrap the hook in a try/catch". It is to make the hook do less, and to make what it does robust: - **Seed through the API, not the UI.** A `beforeEach` that clicks through the catalogue to create a borrow record has as many failure modes as a test; one that posts the record with `cy.request()` or a `cy.task()` has very few. - **Keep navigation and assertions apart.** Assertions inside a hook turn an unrelated regression into a whole-suite outage. Assert in the test. - **Put required resets in `before`/`beforeEach`, never in `after`/`afterEach`.** Teardown is not guaranteed to run, and a teardown that fails takes the block with it as well. - **Split the block.** If one hook is the shared prerequisite for fourteen tests, it is also a single point of failure for fourteen tests. Two smaller `describe` blocks with narrower hooks fail smaller. - **Watch for hooks that grow.** A hook that has accumulated a login, a seed, a cookie and a feature flag is where a spec's flakiness usually lives.