skip to content

Cypress clears aliases before every test — when should a suite share setup instead?

level: principalimportance: should knowfreq 33%

answer

  1. Ask what is shared, not how slow
  2. Isolation is the thing being spent
  3. Read-only versus anything a test mutates
  4. Every test must still pass alone
  5. Measure the saving before trading it

basics

~20 s

Share setup only when the value is read-only for the whole file, expensive to produce, and identical for every test. Anything a test can mutate stays per test, because a shared mutable value makes the suite order-dependent and unreproducible locally.

solid answer

~50 s

I treat the per-test alias reset as a guarantee I am choosing to spend, not an inconvenience. The question is what the shared thing is, not how slow the setup is. Read-only reference data — a catalogue's title count, a fixture, a payload no test edits — is safe to produce once and re-alias per test. Anything a test creates, borrows, returns or edits is not, because the second test then depends on what the first one did. The costs are concrete: a failure in the first test can cascade, a developer cannot run one test alone and get the same result, and the file can no longer be split across machines without thought. So I set the bar at read-only and cheaply rebuildable, require that every test still passes when run by itself, and measure the saving before trading isolation for it.

go deeper

for a junior

Not a question you will be asked yet. What helps is knowing that each Cypress test starts with an empty alias registry, so nothing you name in one test is visible in the next.

for a middle

Be able to describe both shapes — setup repeated per test, and expensive setup hoisted with its result re-aliased each test — and name one concrete risk of the second.

for a senior

Expect to justify a specific call on a suite you own: which steps you hoisted, what evidence said those were the expensive ones, and how you proved every test still passes individually.

for a principal

Own the standard rather than the individual case. State what may be shared, what must never be, how the rule is enforced, and what runtime saving would make the trade worth revisiting.

## What the reset actually guarantees Cypress clears its alias registry before every test, unconditionally. The practical effect is not really about aliases — it is that **no test can inherit a name from the test before it**. A spec's tests can therefore be run in any order, run individually while you debug one of them, or split across machines, and each still sees only the state its own hooks built. That guarantee is the thing on the table. Any proposal to share setup across tests is a proposal to spend some of it, so the useful question is what you get back. ## Find out what actually costs the time The reset itself costs nothing measurable. The cost is in what the hooks do, and on most suites the breakdown is dominated by a few items: - a page visit and the application bootstrap behind it, repeated per test; - signing in or building an account through the interface; - a request or task that produces reference data every test then consumes; - waiting for the application to settle before the first assertion. Only some of those are shareable, and usually only one or two matter. A team that hoists everything because the suite "feels slow" has generally spent the isolation guarantee on the wrong item. ## The test I apply | the shared thing | share it? | why | |---|---|---| | reference data no test changes | yes | every test sees the same value in any order | | a fixture or configuration payload | yes | immutable by construction | | a record a test edits, deletes or moves | no | the second test now depends on the first | | anything the application invalidates over time | no | the failure arrives late and reads as flake | The rule I would write down is short: **shareable means read-only for the whole file, and cheap to rebuild if it is ever wrong.** Everything else is created per test, whatever that costs. ## The costs to name out loud 1. **Cascading failures.** If the first test damages the shared thing, later tests fail for reasons unrelated to what they were testing, and the report points at the wrong place. 2. **Local and CI disagree.** A developer running one test takes a different setup path from CI running the whole file, which is precisely where "works on my machine" comes from. 3. **Sharding gets harder.** A file whose tests depend on one another cannot be split, so the suite's parallelism ends up capped by its slowest file. 4. **The rule erodes.** Once one shared value exists the next is easier to justify, and nobody re-checks whether the first is still read-only. ## What I would put around it - Keep shared values in one obvious place at the top of the spec, named so a reader knows they are shared. - Freeze or copy them before a test can touch them, rather than trusting that nobody will. - Require that every test passes when run by itself, and check that often enough for order dependence to surface the week it appears rather than a quarter later. - Re-register the alias per test rather than reaching for a previous test's state, so the alias stays a per-test object even when the value behind it does not. - Record the measured saving beside the shared value. If it turns out to be a couple of seconds, take the isolation back. ## The version of this answer that is usually right For most suites the correct call is narrow: hoist the one or two genuinely expensive, genuinely read-only steps, leave everything else per test, and take Cypress's per-test alias reset as free enforcement of the rest. The alternative — sharing broadly to make a suite fast — reliably produces a suite that is fast and untrustworthy, and the second property costs more engineering time than the first saves. If a suite is slow enough that this trade looks attractive across the board, the real problem is usually the amount of work each test does through the interface, not the fact that Cypress starts each test with an empty registry. The judgement an interviewer is listening for is that you treated isolation as a **budget you are spending**, priced it, and left behind a rule someone else can follow — not that you found a clever way around a runner's default.

  • How do you keep a shared Cypress setup honest once a team adopts it?
    Make the rule checkable rather than cultural. Shared values live in one clearly named place, they are frozen or copied before a test can touch them, and the suite is run in single-test and reordered forms often enough that order dependence surfaces early. If a shared value ever has to be rebuilt mid-file, that is the signal it should have been per test all along.
  • A team proposes hoisting all of a Cypress spec's setup out of the per-test hook to halve its runtime. What do you say?
    That the alias reset is not the expensive part, so it is the wrong lever. The saving comes from the setup work itself, which can be hoisted selectively without giving up the guarantee that each test starts from a known state. I would ask for the measured breakdown first, hoist the two or three slowest read-only steps, and leave the rest per test.

saying these in an interview costs you the question

  • Treats the alias reset as an obstacle to route around
  • Shares mutable data to save a few seconds
  • Cannot say what a shared value costs the suite
  • Assumes the tests will always run in file order