Detect Order-Dependent Test Coupling in Jasmine with Random Spec Ordering

The hidden failure: specs that pass alone but fail together

A Jasmine suite can look healthy when you run a single spec file, then fail in CI or during a full run. The cause is often order-dependent coupling rather than a bad assertion. One spec mutates a module-level variable, leaves a spy active, or advances jasmine.clock(); a later spec inherits that side effect and breaks. Because Jasmine executes specs in a predictable sequence by default, the coupling remains invisible until file order, timing, or parallel execution changes.

The practical fix is to force the issue: enable Jasmine's random spec ordering, capture the seed reported when a failure appears, and replay that exact order with --seed. That converts a mysterious flake into a deterministic failure you can debug.

Desired outcome

Make hidden inter-spec dependencies visible by running the suite in randomized order. When a failure appears, reproduce it deterministically using the reported seed so you can inspect the leaked state and repair it in setup or teardown hooks rather than by disabling randomization.

Prerequisites

• A Jasmine project with its configuration file (commonly spec/support/jasmine.json) and the Jasmine CLI available in your terminal.
• Confirmation of the exact config filename and option names for your installed major version. Jasmine's configuration schema and CLI flags have changed across major releases; verify against the CLI help or your version's documentation before editing.

Procedure: expose coupling and replay it

1. Enable random ordering

Edit the configuration file to set random to true:

{
  "spec_dir": "spec",
  "spec_files": [
    "**/*[sS]pec.js"
  ],
  "random": true
}

If you prefer not to edit the file, pass the flag on the command line instead:

npx jasmine --random=true

Run this from the project root—the directory containing package.json and your spec folder. No elevated permissions are needed beyond normal read/write access to the project.

2. Capture the failing seed

Run the full suite. When a spec fails under random order, record the seed printed in the output. Capture it immediately; you will need it to replay the same sequence.

3. Replay the exact order

Re-run the suite with the recorded seed to reproduce the failure deterministically:

npx jasmine --seed=<recorded-seed>

Replace <recorded-seed> with the value from the previous run. The expected check is that the same spec fails in the same way. If it does not, the failure may depend on something other than spec order, such as unawaited promises or external timing.

Expected checks and diagnostic meaning

A healthy suite passes across multiple seeds. A failure that appears only under random order signals shared state leaking between specs. The repair belongs in beforeEach and afterEach—reset module state, restore spies, and reset jasmine.clock()—not in disabling randomization.

For comparison, running with --random=false should make the failure disappear if the cause is truly order-dependent. That is a useful confirmation, but it is a diagnostic step, not a solution.

Recovery options for isolating flaky specs

• Confirm the dependency: Run npx jasmine --random=false to verify the suite passes in default order. This tells you the problem is coupling, not a broken assertion.
• Focus the failing spec: Temporarily rename the enclosing describe to fdescribe or the it to fit so Jasmine runs only that spec. Remove the f prefix before committing.
• Inspect leaked state: Look for module-level variables mutated by one spec and read by another, spies that are not restored, and jasmine.clock() state that is not reset. Move cleanup into afterEach.

Fail-fast guardrails during triage

When a suite has many failures, you can fail fast to reduce noise. In the configuration file, stopSpecOnExpectationFailure stops a spec after its first failed expectation, and stopOnSpecFailure stops the run after the first failed spec. Both change reporting behavior. Enable them only while isolating the root cause, then revert them to their normal values so the suite reports all failures again.

Limitations and practical verification

• Config schema varies: Option names and file locations differ across Jasmine major versions. Verify random, seed, and the fail-fast flags against your installed version rather than assuming a single format.
• Seeds are fragile: A seed reproduces order only when the spec list and file set are unchanged. Adding or removing specs changes the sequence.
• Random ordering is not async cleanup: Unawaited promises can still produce nondeterministic failures. Random order exposes coupling; it does not replace proper async handling.
• Do not disable randomization permanently: Turning random ordering off to force a green build hides coupling and usually returns as flakiness later.

How to verify the result

Run the suite twice with different explicit seeds and confirm identical pass/fail results for each seed. As a sanity check, temporarily introduce a shared variable mutated by one spec and read by another; random ordering should surface the failure, and a fixed seed should reproduce it. Remove the temporary variable afterward. Finally, run the suite with --random=true several times with no seed argument to confirm the failure no longer appears.