vEnhance / otis-web / 19577630329

94%

push

github

fix: actually fix roster test omfg (#436)

* fix: eliminate flakiness in test_inquiry with parallel execution

The test_inquiry test was failing intermittently when run with pytest -n auto
due to random subject assignment in UnitFactory. When units[19] (the 7th unit
Alice tries to unlock) randomly got subject="K" (Secret), it would be auto-
processed by the view logic at roster/views.py:351-352, even though the test
expected it to NOT be auto-processed.

The view auto-processes secret units (subject "K") regardless of the student's
unlock count, which caused the test assertion to fail approximately 12.5% of
the time (1 in 8 possible subjects).

Fixed by explicitly creating units with non-secret subjects (A, C, G, N, F)
instead of relying on random factory generation. The test later creates an
explicit secret unit when testing that functionality.

* fix: avoid IntegrityError from unique_together constraint in test_inquiry

The previous fix introduced a new IntegrityError due to Unit's unique_together
constraint on (group, code). By creating only 5 UnitGroup objects and reusing
them for 20 Units, we hit a birthday paradox problem:

- Unit.code is randomly generated: choice("BDZ") + subject + choice("WXY")
- This gives only 9 possible codes per group (3 × 1 × 3)
- With 4 units per group (20 units ÷ 5 groups), probability of collision ≈ 54%

The fix: Create 20 separate UnitGroup objects (one per unit) to avoid any
possibility of code collision within a group. We still cycle through non-secret
subjects (A, C, G, N, F) to prevent the original flaky test issue where
subject="K" (Secret) would trigger auto-processing.

* style: apply ruff formatting to test_inquiry

---------

Co-authored-by: Claude <noreply@anthropic.com>

8 of 216 branches covered (3.7%)

Branch coverage included in aggregate %.

1079 of 1687 relevant lines covered (63.96%)

0.64 hits per line