S'attaquer au problème des tests instables

Les Tests instables, c'est un truc courant dans le développement logiciel. Ces tests passent parfois et échouent parfois, sans que le code qu'ils testent ait changé. Cette incohérence peut embrouiller les développeurs et leur faire perdre du temps. Par exemple, si un test échoue, les développeurs peuvent penser qu'il y a un souci avec le code. Mais en fait, l'échec peut juste venir du test lui-même qui est instable.

#Pourquoi les tests instables sont-ils un problème ?

Les tests instables peuvent causer des retards dans le déploiement des logiciels. Beaucoup de grandes boîtes, comme Google et Microsoft, ont reporté des milliers d’échecs de tests instables. Par exemple, Google a eu environ 1,6 million d'échecs de tests par jour, avec un petit pourcentage causé par des tests instables. Détecter et corriger ces tests instables demande beaucoup d'efforts et peut ralentir le processus de développement.

#Causes des tests instables

Plusieurs facteurs peuvent rendre les tests instables :

1. Problèmes de timing : Les tests peuvent échouer à cause du timing de certaines opérations, surtout dans les systèmes qui exécutent plusieurs tâches en même temps.
2. Configuration de l'environnement : Des différences dans les environnements de test peuvent affecter les résultats des tests.
3. Dépendances externes : Les tests instables peuvent dépendre de systèmes externes ou de données qui peuvent changer, causant des incohérences.
4. Conditions de course : Ça se produit quand le timing des événements affecte le comportement du logiciel.

#Comment sont gérés les tests instables ?

Actuellement, beaucoup de développeurs détectent les tests instables en les relançant ou en les inspectant manuellement. Bien que certains chercheurs aient utilisé l'apprentissage automatique pour prédire les tests instables, il y a eu moins d'attention sur comment aider les développeurs à corriger ces tests une fois qu'ils sont identifiés comme instables.

#Solution proposée

Pour aider les développeurs à corriger les tests instables, un nouveau cadre a été proposé. Ce cadre catégorise automatiquement les corrections de tests instables en fonction du code des tests. En analysant seulement le code des tests, le cadre peut suggérer quel type de correction peut être nécessaire.

#Catégories de corrections

La solution proposée inclut 13 catégories de corrections pour les tests instables. Ces catégories aident les développeurs à savoir où concentrer leur attention. Voici quelques exemples :

1. Changer l'assertion : Modifier ce que le test vérifie pour améliorer sa fiabilité.
2. Réinitialiser les variables : S'assurer que les variables sont réinitialisées avant que les tests ne soient exécutés.
3. Gérer les exceptions : Ajouter une meilleure gestion des erreurs pour éviter les échecs dus à des entrées inattendues.

#Modèles de langage en action

Le cadre utilise des modèles de langage pré-entraînés comme CodeBERT et UniXcoder. Ces modèles analysent le code des tests et prédisent quelle catégorie de correction s'applique. Quelques techniques sont utilisées pour améliorer les prédictions. Une méthode implique l'apprentissage par Few-Shot (FSL), qui permet aux modèles d'apprendre à partir d'un nombre limité d'exemples.

#Évaluation du cadre

Pour évaluer l'efficacité de ce nouveau cadre, les chercheurs ont mené des expériences pour comparer les performances des deux modèles de langage. Les résultats ont montré que :

• UniXcoder a généralement mieux prédit les catégories de correction que CodeBERT.
• FSL n'a pas vraiment amélioré les prédictions, probablement à cause de la taille limitée du dataset disponible pour l'entraînement.

Les modèles ont bien performé pour prédire les catégories de correction, avec la plupart des catégories atteignant une haute précision. Ça veut dire que le cadre peut fournir des conseils utiles aux développeurs en corrigeant les tests instables.

#Création d'un dataset

Pour construire un bon modèle de prédiction, il était essentiel d'avoir un dataset étiqueté de tests instables et leurs corrections correspondantes. Les datasets existants avaient des limitations, donc les chercheurs ont créé leur propre dataset en analysant différentes sources. Ils se sont concentrés sur les tests pouvant être corrigés en changeant le code des tests, plutôt que ceux nécessitant des changements dans le code de production ou la configuration de l'environnement.

#Défis à relever

Bien que le cadre proposé soit utile, il y a encore des défis à relever :

1. Limitations des données : Il faut plus de données pour de meilleures prédictions. Les performances du modèle peuvent faiblir si les données d'entraînement sont insuffisantes.
2. Généralisation : Le cadre doit être testé sur différents langages de programmation et des datasets plus variés pour s'assurer qu'il fonctionne bien dans divers environnements.
3. Tests instables complexes : Certains tests instables peuvent nécessiter plusieurs corrections, ce que le cadre actuel pourrait ne pas pouvoir gérer.

#Développements futurs

Le cadre peut être étendu et amélioré. Les efforts futurs se concentreront sur la construction de plus grands datasets pour affiner encore l'exactitude du modèle. De plus, la recherche pourrait mener à des modèles de réparation entièrement automatiques qui peuvent suggérer des changements de code spécifiques en fonction des tests instables identifiés.

#Conclusion

Les tests instables représentent un défi important pour les développeurs. Le cadre proposé offre une solution prometteuse pour catégoriser les corrections en fonction du code des tests, fournissant des conseils pratiques aux développeurs. L'utilisation de modèles de langage avancés montre un potentiel pour aider les développeurs à identifier rapidement les changements nécessaires. Les travaux futurs amélioreront les capacités du cadre, pouvant mener à des outils d'automatisation plus robustes pour la réparation des tests dans le développement logiciel.