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

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

Les tests irréguliers sont un problème courant dans Chrome. Ils impacter la productivité des autres développeurs, et s'éteint, au fil du temps. Si les tests sont désactivés, la couverture des tests 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 bogue concernant un test irrégulier, passez quelques minutes et commentez ce qui s'est mal passé sur le bug. Si vous avez un ancien test irrégulier et Si vous ne savez pas ce qui s'est passé, essayez simplement de réactiver le test. Réattribuez le bug dès que possible s'il s'agit clairement d'un problème lié à un autre composant. Les propriétaires de ce composant devraient avoir un meilleur jugement sur l’échec,

Étape de débogage

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

Utilisez des outils de remplacement si le débogueur supprime les problèmes de fiabilité. Il est il est possible que, avec le débogueur, le test ne soit jamais irrégulier. Dans ce cas, consignez ou base::debug::StackTrace peuvent être utiles.

À éviter

Outre les bugs en production, gardez à l'esprit les raisons courantes des échecs de EXPECT__* code:

  • Exigences incorrectes (par exemple, "page sécurisée" signifie "HTTPS" et "localhost").
  • Conditions de concurrence en raison de tests qui n'attendent 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 peuvent être remplacés par trois à l'avenir, ce qui rend le test instable. Cependant, seul l'état du magasin est pertinent. Utilisez plutôt un observateur pour Google Store.

À éviter

Méfiez-vous des schémas courants, tels que les suivants:

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

L'extrait de code ci-dessus issu d'un test effectué dans un navigateur est presque sûrement incorrect. Il y a de nombreux événements qui doivent se produire dans différents processus et les threads avant qu'une interface utilisateur ne s'affiche.

À faire

Voici une solution correcte:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

La correction ci-dessus est correcte, considérant que WaitUntilCredentialPromptVisible() ne vérifie pas l'UI. Les tests du navigateur ne doivent pas dépendre d'événements d'interface utilisateur externes (par exemple, "mise au point perdue"). ou "la fenêtre est devenue premier plan". Imaginez une implémentation où la requête apparaît uniquement lorsque la fenêtre du navigateur est active. Une telle implémentation serait correct. Toutefois, en vérifiant la fenêtre réelle, le test est irrégulier.

Étape post-correction

Une fois le test corrigé, exécutez-le des centaines de fois en local. Gardez un œil sur Portail Flakiness.