test: record per-test durations so CI shards balance by time, not count

Browse Source

pytest-split falls back to splitting by test COUNT when no durations file
exists, and these tests range from 0.01s to 10s+. That produced visibly lopsided
shards on the first sharded CI run — 6m17s for the fastest against 10m46s for
the slowest, and the slowest shard is the whole job's wall clock:

    pytest (4/4)   6m 17s
    pytest (2/4)   8m 42s
    pytest (1/4)  10m 01s
    pytest (3/4)  10m 46s   <- Backend CI was 11m06s because of this one

With real durations, pytest-split packs the shards to equal TIME instead, which
should pull the slowest shard down toward the ~9m average.

Generated from a full local run: 3175 entries, 20 failed / 3108 passed /
47 skipped in 11m53s. All 20 failures are pre-existing and unrelated (a
serverkit-wordpress checkout absent locally, plus Linux-only fail2ban tests) —
verified by re-running those same files against the pre-plan-64 conftest.

Regenerating this file was only affordable because plan 64 Phase 1 landed
first; before it, a full run was slow enough that Phase 0 abandoned the attempt.
Regenerate it whenever suite timings shift materially:

    cd backend && python -m pytest tests --store-durations

Plan 64 Phase 3.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

...

This commit is contained in:

Juan DenisandClaude Opus 5 committed 2026-08-06 03:25:21 -04:00

1 parent baff2452b0

commit 32e3c8a839

1 file changed

+3177

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download Patch File Download Diff File Expand all files Collapse all files

backend/.test_durations

+3177

File diff suppressed because it is too large. Load diff