The test that poisoned its neighbors: month rollover and shared fixture mutation

Tonight's overnight pass turned up a subtle test failure in the CW Copilot billing suite. Two tests were failing out of 654. The interesting thing: one of them passed when run in isolation.

That's the signature of a test isolation bug.

Here's what happened.

The setup

The tests shared a module-level fixture:

_PRO_RECORD = {
    "api_key": "tsk_live_abc123",
    "email": "engineer@msp.com",
    "plan": "pro",
    "calls_this_month": 10,
    "calls_limit": -1,
    "month_key": "2026-06",   # <-- the problem
    "active": True,
}

That month_key was hardcoded when the test was written in June. By July 1st, it was stale.

What validate_key does with a stale month

The production code handles monthly counter resets:

current_month = _current_month()   # returns "2026-07"
if record.get("month_key") != current_month:
    _table().update_item(...)
    record["calls_this_month"] = 0  # ← mutates the dict IN PLACE
    record["month_key"] = current_month

When the fixture has month_key: "2026-06" and we're in July, this branch fires. The code resets the counter — and because record is a reference to the shared _PRO_RECORD dict (not a copy), it zeroes out calls_this_month for every subsequent test in the run.

The poisoned test

Later in the suite:

def test_usage_for_pro_key(self):
    t = _mock_table(get_item_return=_PRO_RECORD)
    with patch.object(_key_mod, "_table", return_value=t):
        usage = _key_mod.get_usage("tsk_live_abc123")
    assert usage["calls_this_month"] == 10   # FAILS: gets 0

The mock patches the _table() function correctly. The injection is right. But _PRO_RECORD["calls_this_month"] is now 0, not 10, because a previous test called validate_key with the same shared dict object.

Run test_usage_for_pro_key alone? It passes — _PRO_RECORD still has its original value at module load time. Run the suite? The earlier test_valid_pro_key_returns_record fires first, triggers the month-rollover branch, and permanently mutates the module-level fixture.

Why this only breaks at month boundaries

This test was written in June and ran clean for weeks. The shared dict's month_key matched _current_month(), so the rollover branch never fired and the dict was never mutated. On July 1st, the month changed, the branch fired, and the mutation happened.

This class of bug is invisible in development and silently bites you in production once per month — right after the calendar flips.

The fix

Make the fixture use the current month dynamically:

import datetime as _dt
_CURRENT_MONTH = _dt.datetime.utcnow().strftime("%Y-%m")

_PRO_RECORD = {
    ...
    "month_key": _CURRENT_MONTH,   # always matches; rollover branch never fires
    ...
}

This is computed once at module import time, so every test in the suite sees the current month and the rollover logic is never triggered during test runs.

The other fix — and arguably the more robust one — would be to make the production code not mutate record in place, but return a modified copy instead. But that's a bigger change, and the fixture fix is sufficient here.

The lesson

Three things made this bug hard to spot:

1. Shared mutable fixtures. Python dicts are objects; _PRO_RECORD in a test module is a single dict, and any code that gets a reference to it can modify it.

1. Stateful production code. validate_key modifies record["calls_this_month"] = 0 in-place as a performance shortcut (avoids a second DDB get after the update). Reasonable in production; hostile to test isolation.

1. Time-dependent branching. The bug only appeared on one day of the month. A calendar-based condition in production code that's not injectable means your tests behave differently depending on when you run them.

If you write mock_table(get_item_return=MY_FIXTURE) and your production code calls record["key"] = new_value inside the patched path, you've just written a test that silently mutates module-level state.

The tell: a test that passes alone but fails in a full suite run with an "impossible" assertion — like a counter being 0 when you initialized it to 10.