Flakiness : Quand tester, c’est vraiment douter - Maxime CLEMENT (Docker)

Summary

Cette présentation explique comment une équipe de développement a abordé le problème des tests instables (flaky tests) dans leur pipeline d'intégration continue. Plutôt que d'essayer d'éliminer totalement ces tests, l'équipe a automatisé leur gestion en utilisant un outil appelé 'Skipper'. Cet outil permet de suivre les tests instables et de les ignorer si nécessaire, sans risquer de masquer de régressions. En automatisant cette gestion, l'équipe a économisé un temps précieux et optimisé l'utilisation des ressources, tout en maintenant une qualité de produit stable.

Takeaways

• 😀 L'un des principaux problèmes rencontrés avec les tests est leur caractère instable (flaky), ce qui peut entraîner une perte de temps et de ressources pour les développeurs.
• 😀 Les développeurs ignorent souvent les tests instables ou les relancent plusieurs fois, ce qui conduit à un comportement inefficace dans le processus de développement.
• 😀 L'objectif était d'automatiser le processus d'identification et de gestion des tests instables afin de réduire les frictions pour les développeurs et d'améliorer l'efficacité.
• 😀 Le système développé, appelé Skipper, collecte des données sur les résultats des tests à partir de toutes les branches et stocke ces informations dans une base de données pour être utilisées ultérieurement.
• 😀 Skipper utilise ces données pour déterminer si un test échoué est dû à une instabilité connue (flaky) ou s'il s'agit d'un échec réel, permettant ainsi de l'ignorer ou de le traiter comme une régression.
• 😀 La mise en place d'un tableau de bord a permis de mieux visualiser la fréquence des tests instables, les plates-formes concernées, et les équipes travaillant sur ces problèmes.
• 😀 Grâce à cette automatisation, les développeurs peuvent continuer leur travail sans attendre que tous les tests passent, tout en étant avertis des tests instables qu'ils choisissent d'ignorer.
• 😀 L'automatisation a permis de réduire le nombre de tentatives de relance des tests, économisant ainsi un temps précieux et réduisant les ressources informatiques utilisées.
• 😀 Skipper a également permis aux équipes de gérer elles-mêmes leurs tests instables, en leur offrant la possibilité de corriger les tests en fonction de leurs priorités et échéances.
• 😀 Bien que l'automatisation ait apporté des gains d'efficacité, la qualité du produit n'a pas été dégradée, et au contraire, des indicateurs ont montré une amélioration de la qualité au fil du temps.
• 😀 Le principe derrière l'approche était que la perfection dans les suites de tests n'est pas toujours nécessaire et que l'accent doit être mis sur la résolution des véritables problèmes plutôt que sur la recherche de perfection.

Q & A

Qu'est-ce qu'un test instable (flaky test) et pourquoi est-il problématique ?

Un test instable est un test qui échoue de manière intermittente, même si le code testé est correct. Cela peut être dû à des problèmes externes, comme des écritures sur disque. Les tests instables sont problématiques car ils ralentissent le processus de développement, en obligeant les développeurs à relancer les tests ou à les ignorer, ce qui peut mener à des décisions incorrectes basées sur des résultats de tests erronés.

Comment les développeurs géraient-ils les tests instables avant l'implémentation de Skipper ?

Avant l'implémentation de Skipper, les développeurs géraient les tests instables en les ignorant ou en relançant les tests jusqu'à ce qu'ils passent. Si un test échouait de manière récurrente pour une raison spécifique, ils acceptaient de l'ignorer, espérant qu'il ne provoquerait pas d'impact majeur sur le développement.

Quel rôle joue l'outil Skipper dans la gestion des tests instables ?

Skipper automatise la gestion des tests instables en collectant des données sur les échecs des tests à travers tous les branches et en analysant leur comportement. Il permet de décider automatiquement si un test échoué est dû à un problème récurrent (flaky) et donc peut être ignoré, ou s'il s'agit d'un échec inattendu, considéré comme une régression réelle.

Comment Skipper détermine-t-il si un test peut être ignoré ?

Skipper détermine si un test peut être ignoré en analysant les données historiques des tests échoués. Si un test échoue régulièrement de la même manière et que l'erreur est identifiée comme un échec récurrent (flaky), Skipper l'ignore. Si le test échoue avec une nouvelle erreur jamais vue auparavant, il est considéré comme une régression réelle et doit être traité.

Quel impact Skipper a-t-il eu sur le temps des développeurs ?

Skipper a permis de gagner un temps précieux pour les développeurs en leur évitant de relancer des tests plusieurs fois ou de perdre du temps à traiter des échecs récurrents. Grâce à Skipper, environ 300 demandes de fusion par mois ont pu être acceptées sans attendre que les tests passent, ce qui a considérablement réduit la surcharge de travail liée aux tests.

Comment l'audit des tests instables fonctionne-t-il dans le système Skipper ?

Skipper inclut un système d'audit pour suivre les tests qui ont été ignorés et examiner si des décisions de suppression étaient justifiées. Cela permet de détecter les erreurs possibles dans l'automatisation du processus et d'affiner les règles pour mieux gérer les tests flakys à l'avenir.

Quels résultats concrets ont été obtenus après l'implémentation de Skipper ?

Après l'implémentation de Skipper, l'équipe a pu économiser une année de calcul par mois en évitant les re-tests inutiles de tests instables. De plus, la qualité globale des tests et du produit est restée stable, voire a amélioré, malgré l'acceptation de tests flakys dans le processus de développement.

Skipper a-t-il dégradé la qualité du produit ?

Non, l'acceptation de tests instables n'a pas dégradé la qualité du produit. En fait, les métriques de qualité de test et de produit ont montré une tendance à la hausse, prouvant que les tests flakys n'ont pas eu d'impact négatif majeur sur la qualité du produit final.

Quel est l'argument principal de l'approche de Skipper par rapport à la perfection des tests ?

L'argument principal est que la perfection des tests n'est pas toujours un objectif réaliste ou rentable. Plutôt que d'essayer de supprimer tous les tests instables, l'approche de Skipper se concentre sur la gestion de leur impact et sur la réduction de la friction qu'ils causent aux développeurs, permettant ainsi un développement plus rapide et plus fluide.

Comment les équipes sont-elles incitées à résoudre les tests flakys dans le système Skipper ?

Les équipes sont incitées à résoudre les tests flakys grâce à des notifications automatisées via un bot Slack qui leur rappelle régulièrement l'état des tests flakys. Elles peuvent également choisir quand résoudre ces problèmes en fonction de leurs priorités, mais elles reçoivent des encouragements pour les résoudre en temps utile.