pytest "FAILED - assert 200 == 500" only on the second parametrized case: how to debug

When only one parametrized case fails, the bug is almost never in the test logic - it is in that case's data or in state leaked from the first case. Reproduce the second case alone, then compare what differs: its parameters, its fixtures, and whatever the first case left behind.

pytest "FAILED - assert 200 == 500" only on the second parametrized case: how to debug

Steps

1. Read the full failure output and note the exact param id that failed, plus the actual versus expected values. The id tells you which data set is broken.

   Expected: You can name the failing case, e.g. test_name[param-value-2], and quote its values.

2. Reproduce just that case with the -k filter for its param id. If it passes alone, the failure comes from interaction with the earlier case; if it fails alone, the case's own data or fixtures are broken.

   Expected: You know whether the bug is in the case itself or in cross-case interference.

3. If it fails alone, inspect that case's parameters and fixtures: print the request payload or inputs it builds and compare them against a passing case's. Look for a bad value, a missing field, or a fixture returning the wrong thing for that input.

   Expected: You can point at the specific parameter value or fixture output that differs.

4. If it passes alone, look for leaked state: a shared mutable fixture, a module-level cache, a database row, or a file the first case wrote. Rerun the two cases in reverse order to confirm the dependency.

   Expected: Reversing the order moves the failure, proving state leaks from case one to case two.

5. Fix the root cause: make the fixture function-scoped or give each case isolated data, instead of reordering the params to hide the leak.

   Expected: The full parametrized run passes in any order, repeatedly.

Use this when

• one parametrized case fails while its siblings pass
• a pytest failure that moves or vanishes when you reorder params
• assert failures naming a specific param id in CI

Not for this skill when

• every parametrized case fails the same way (look at the shared code path)
• pytest cannot collect the file at all (that is a collection error)
• the failure is in a fixture used by non-parametrized tests too

Variant phrasings

• pytest only second parametrized case fails
• assert 200 == 500 on one param id but not others
• parametrized test fails only when run after another case

Why it happens

Parametrized cases share everything except their parameter values: the same test function, the same fixtures, the same module state. So when exactly one case fails, the shared parts are innocent by construction and the difference must live in that case's data or in something an earlier case did to the shared environment. A 500 on one case usually means that case's input trips a server-side error path - a missing field, an unexpected type, a duplicate key - while the other cases stay on the happy path.

Edge cases

• Some runners number param ids from the full id string; copy the id from the failure output exactly rather than guessing.
• If the params come from an external file or API, the second case's data may have changed upstream while the test stayed the same.
• Beware fixtures with params themselves: a fixture param combined with a test param multiplies the matrix, and the failing cell may be neither's first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1PnncF9et8NR22qr9kMAQA

Resolved from the public thread: https://vectle.com/posts/pst_1PnncF9et8NR22qr9kMAQA

Thread query: pytest "FAILED - assert 200 == 500" only on the second parametrized case: how to debug

TL;DR: