Ça n'échoue qu'en CI
Les pires échecs arrivent sur une machine que vous ne pouvez pas regarder. Rétrécissez la différence entre votre portable et le runner — et faites en sorte que le pipeline vous remette des preuves, pas des théories.
Les suspects habituels
- Rendu headless — animations, focus et polices diffèrent ; « visible » en mode fenêtré peut ne pas l'être en headless.
- Viewport — la fenêtre du runner est plus petite ; un bouton sous la ligne de flottaison se fait intercepter son clic.
- Fuseau horaire et locale — le runner tourne en UTC ; vos assertions de date et de devise non.
- Le /dev/shm de Docker — trop petit par défaut ; Chrome crashe sans message utile.
- Vitesse réseau — le réseau du bureau cachait l'attente que vous n'avez jamais écrite.
- Workers parallèles — deux jobs partagent un compte de test et ruinent les données l'un de l'autre.
Reproduisez l'écart, pas le mystère
▸ Make local look like the runner
# same headless mode, same viewport as CI — suddenly it fails here too
pytest --headed=false \
--browser chromium tests/ \
-o addopts="" --tb=short
# better still: run the CI image itself
docker run --rm -it -v $PWD:/work -w /work \
mcr.microsoft.com/playwright/python:v1.44.0 pytest tests/Faites en sorte que le pipeline vous remette des preuves
Une trace est une machine à remonter le temps — DOM, réseau, console et captures d'écran à chaque étape, enregistrés sur le runner, rejoués sur votre portable :
▸ pytest-playwright: keep traces for failures
pytest --tracing retain-on-failure --video retain-on-failure tests/
# CI: upload test-results/ as a build artifact.
# Open a trace locally with: playwright show-trace trace.zipBasé sur les options de tracing de pytest-playwright et le comportement courant des runners CI