Chromium Chronicle n°2: Combattre les irrégularités

Épisode 2:de Vasilii à Munich (mai 2019)
Épisodes précédents

Les tests irréguliers sont un problème courant dans Chrome. Ils ont un impact sur la productivité des autres développeurs et sont désactivés au fil du temps. Si vous désactivez les tests, la couverture de test diminue.

Étape de tri

Les PROPRIÉTAIRES des répertoires sont chargés de corriger leurs tests irréguliers. Si vous avez reçu un bug à propos d'un test irrégulier, prenez quelques minutes et commentez ce qui s'est mal passé. Si vous avez un ancien test irrégulier et que vous ne parvenez pas à identifier la cause du problème, essayez simplement de le réactiver. Réattribuez le bug dès que possible s'il concerne clairement un autre composant. Les propriétaires de ce composant devraient mieux juger de l'échec,

Étape de débogage

Un certain nombre d'indicateurs de ligne de commande sont utiles pour corriger les tests irréguliers. Par exemple, --enable-pixel-output-in-tests affiche l'UI réelle du navigateur.

disposer d'outils de remplacement si le débogueur fait disparaître les irrégularités ; Il est possible que, avec le débogueur, le test ne soit jamais irrégulier. Dans ce cas, les instructions de journal ou base::debug::StackTrace peuvent être utiles.

À éviter

Gardez à l'esprit les raisons les plus courantes de défaillances de EXPECT__* en plus des bugs dans le code de production:

  • Attentes incorrectes (par exemple, "page sécurisée" signifie HTTPS ; il peut s'agir d'un hôte local).
  • Conditions de concurrence causées par des tests n'attendant pas le bon événement.

[Ne testez pas l'implémentation][not-implementation], mais le comportement.

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

Les deux allers-retours sont susceptibles de changer en trois à l'avenir, rendant le test irrégulier. Toutefois, seul l'état du magasin est pertinent. Utilisez plutôt un observateur pour le magasin.

À éviter

Méfiez-vous des modèles courants tels que les suivants:

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

Un extrait de ce type provenant d'un test de navigateur est presque sûrement incorrect. De nombreux événements doivent se produire dans différents processus et threads avant qu'une interface utilisateur n'apparaisse.

À faire

Voici une solution correcte:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

La correction ci-dessus est correcte, car on part du principe que WaitUntilCredentialPromptVisible() ne vérifie pas réellement l'interface utilisateur. Les tests du navigateur ne doivent pas dépendre d'événements d'interface utilisateur externes tels que "focus perdu" ou "la fenêtre est passée au premier plan". Imaginons une implémentation dans laquelle l'invite n'apparaît que lorsque la fenêtre du navigateur est active. Une telle implémentation serait correcte. Toutefois, la vérification de la fenêtre réelle rend le test irrégulier.

Étape après correction

Une fois le test résolu, exécutez-le des centaines de fois en local. Surveillez le portail Flakiness.