Architecture de framework & CI/CD · Leçon 6 sur 6

Parallèle, réessais & quarantaine des tests instables

Un framework senior est à la fois rapide et honnête. Vous tirerez deux leviers ici — exécuter les tests en parallèle, et gérer les tests instables sans mentir sur la qualité.

Par Shahriyar · Mis à jour

L'idée, en une ligne

Exécutez les tests en même temps pour aller plus vite, et mettez les tests instables en quarantaine au lieu de les cacher. Vitesse et honnêteté, gardées séparées.

Exécuter en parallèle

Les exécutions parallèles viennent de pytest-xdist. -n auto démarre un worker par cœur CPU ; -n 4 fixe le nombre. Parce que les workers exécutent les tests dans n'importe quel ordre, ça ne marche que si vos tests sont indépendants — pas d'état mutable partagé, pas d'hypothèses sur l'ordre. Si certains tests doivent rester ensemble, --dist loadscope les groupe par module ou classe par worker.

Réessayer de la bonne façon

Les réessais viennent de pytest-rerunfailures. --reruns 2 relance un échec, --reruns-delay 1 attend une seconde entre les tentatives, et --only-rerun limite les réessais à des erreurs spécifiques — réessayez un timeout, jamais un AssertionError. Les réessais faits à la légère cachent de vrais bugs, alors cadrez-les serré.

▸ try it
# Fast: one worker per core; keep related tests together
# pytest -n auto --dist loadscope

# Tight retries: only network flakiness, never assertions
# pytest --reruns 2 --reruns-delay 1 --only-rerun TimeoutError

import pytest

# Quarantine a known-flaky test out of the blocking suite
@pytest.mark.quarantine
@pytest.mark.flaky(reruns=2, reruns_delay=1)
def test_live_search_suggestions():
    ...

# In CI, the main job skips quarantine; a separate job runs it:
#   pytest -m "not quarantine"   # blocking
#   pytest -m "quarantine"       # non-blocking, reported only

Lisez-le de haut en bas : le test instable est étiqueté pour que le build principal le saute, et un job séparé non-bloquant l'exécute et rapporte le résultat sans faire échouer tout le monde.

Avancé — quarantaine avec une échéance

Quand un test devient instable, ne le supprimez pas et ne le laissez pas faire échouer le build pour tout le monde. Marquez-le, exécutez-le dans un job séparé non-bloquant, et ouvrez un ticket pour corriger la cause racine. La quarantaine est un enclos avec une échéance, pas un cimetière — suivez ce qu'il y a dedans ou la liste grandit à l'infini.

Basé sur la documentation pytest-xdist et pytest-rerunfailures

Toutes les leçons de Architecture de framework & CI/CD

  1. Concevoir un framework de zéro : les couches
  2. Les quatre patterns que les SDET utilisent vraiment
  3. Données de test : fixtures vs factories vs ensemencement
  4. CI avec GitHub Actions : exécuter UI + API à chaque push
  5. Docker & Selenium Grid : des environnements de test reproductibles
  6. Parallèle, réessais & quarantaine des tests instables