Test order dependency

A test failed because it depends on side effects or state created by a different test that ran earlier.

order-dependency medium confidence test

Matched signals

  • depends on previous test
  • test order
  • test assumes
  • leaked state
  • global state
  • left over from previous

Test order dependency

What this failure means

A test failed because it depends on side effects or state created by a different test that ran earlier. When test order changes, the assumed preconditions are absent.

Symptoms

Faultline looks for one or more of these log fragments:

depends on previous test
test order
test assumes
leaked state
global state
left over from previous

Diagnosis

A test failed because it depends on side effects or state created by a different test that ran earlier. When test order changes, the assumed preconditions are absent.

Fix steps

  1. Add proper setup and teardown to the failing test so it creates its own required state independently.

  2. Remove shared mutable fixtures between tests; every test should own and clean up its own data.

  3. Run tests in random order to surface all hidden ordering assumptions:

    go test -shuffle=on ./...                  # Go 1.20+
    pytest --randomly-seed=<N>                 # Python, requires pytest-randomly
    jest --randomize                           # Jest 29+
    

    Record and re-use the seed from a failing run to reproduce the exact order:

    go test -shuffle=on -v ./... 2>&1 | grep -E "^-test.shuffle"
    pytest --randomly-seed=<seed from the failing run>
    
  4. Add cleanup in defer (Go), afterEach/afterAll (Jest), or teardown (Python) to guarantee state is reset regardless of test outcome.

Validation

  • Run the full suite with shuffle enabled several times and confirm zero failures across different orderings.
  • Re-run the originally failing test in isolation and confirm it passes.

Why it matters

Tests that rely on database rows, files, or configuration left by prior tests are brittle. Test frameworks may run tests in any order or in parallel, and CI runners may run on clean environments that lack the expected state.

Prevention

  • Treat each test as an independent unit; avoid any shared mutable state.
  • Write cleanup code in defer (Go), afterEach (JS), or teardown (Python).
  • Enable random test ordering in CI to catch ordering assumptions early.

Try it locally

go test -shuffle=on ./...
go test -shuffle=on ./...

How Faultline detects it

Use faultline explain order-dependency to see the full playbook.

faultline analyze build.log
faultline explain order-dependency

Generated from playbooks/bundled/log/test/order-dependency.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.