Instable ou cassé : prouvez-le avec un chiffre

Mesurez-le

pass=0; fail=0
for i in {1..50}; do
  pytest -q tests/test_checkout.py::test_guest_checkout >/dev/null 2>&1 \
    && pass=$((pass+1)) || fail=$((fail+1))
done
echo "passed $pass / failed $fail"
# (pytest-repeat does the same: pytest --count=50 -x <test>)

• 0/50 échoue — l'échec venait de l'environnement. Allez à la leçon 5.
• 4/50 — une race condition à 8 %. Toute trace unique mentira à moitié ; le timing est le suspect.
• 50/50 — pas instable. Cassé. Suivez la trace.

Pourquoi un « petit » taux est un gros problème

Un test qui échoue 0,5 % du temps semble inoffensif. Deux cents comme lui font échouer un build la plupart des jours, et l'équipe apprend à cliquer sur relancer sans lire.

Cette habitude — pas la race condition — est ce qui tue l'automatisation. Google a publié que la plupart de ses échecs de tests réessayés sont de l'instabilité, pas de vraies régressions. Une fois qu'une équipe s'y attend, un vrai rouge se fait ignorer avec le reste.

sleep(2), c'est comme ça que meurent les frameworks

# bad — hides the race, taxes every run forever, still fails on a slow day
time.sleep(2)
page.click("#place-order")

# good — waits exactly as long as the condition takes, and fails honestly
expect(page.locator("#cart-total")).to_have_text("$41.98")
page.click("#place-order")

La sieste ne corrige pas la race condition — elle la déplace. Et elle facture deux secondes, fois chaque test copié, fois chaque exécution, pour toujours.

La quarantaine, avec une trace écrite

Un test mesuré instable est marqué, ticketé et attribué — le même jour. La marque garde le build honnête ; le ticket garde la perte de couverture visible.

Basé sur pytest-repeat et la recherche publiée sur les tests instables de Google et Microsoft