Générer des autotests et des locators avec un réseau de neurones sur un projet legacy : retour d'expérience

L'autrice poursuit sa série pratique sur la génération automatique de tests. Dans ce nouvel article, elle détaille sa méthode pour générer des autotests et des locators sur un gros projet legacy, le temps que cela a pris, les erreurs du modèle et si l'effort en valait la peine.

Ce qu'a montré la partie précédente de la série

Le précédent article de l'autrice posait déjà une conclusion clé : sans README décrivant l'architecture du framework de test, la génération d'autotests sur un gros projet legacy tourne au cycle sans fin de revues et de corrections. Privé de contexte sur le fonctionnement du framework — quelles classes de base utiliser, comment les locators sont organisés, quelles conventions le projet a adoptées —, le modèle propose encore et encore du code qu'il faut réécrire à la main, au lieu de livrer directement un résultat fonctionnel.

Cette conclusion fixe le cadre du nouvel article : une fois la condition de base remplie — l'architecture documentée —, reste la question de la pratique. C'est précisément par là que l'autrice ouvre son nouvel article, en promettant non pas des conseils abstraits, mais un processus concret de génération d'autotests et de locators sur du code réel.

Où la génération de locators bute généralement

Les locators constituent sans doute le point le plus fragile de la génération automatique de tests UI : ils dépendent du balisage précis de la page, souvent instable, incohérent et non documenté dans les projets legacy. Un modèle qui génère des locators sans comprendre en profondeur la structure réelle du DOM d'un écran donné risque de proposer des sélecteurs fragiles : ils cassent à la moindre modification de la mise en page, ou dupliquent des locators déjà présents dans le projet au lieu de réutiliser l'existant.

C'est pourquoi l'autrice se concentre dans ce nouvel article sur trois questions pratiques : combien de temps cette approche fait réellement gagner par rapport à l'écriture manuelle, dans quels scénarios le modèle continue de se tromper même avec un README décrivant l'architecture, et si elle se justifie à l'échelle d'un gros projet legacy, où une erreur dans les tests se paie en faux positifs dans la CI et en temps perdu par l'équipe pour les analyser.

• Format — deuxième article d'une série sur la génération d'autotests et de locators par IA
• Condition issue du premier article — un README décrivant l'architecture du framework est indispensable pour un projet legacy
• Objet du nouvel article — le processus concret, le temps consacré et les erreurs typiques du modèle
• Cible des tests — un gros projet legacy

Ce que cela signifie

L'expérience de ce type de séries le montre : en pratique, générer des autotests avec l'IA ne se résume pas à « je demande, j'obtiens du code qui marche ». Cela exige un travail préparatoire sur le contexte du projet et une évaluation lucide des scénarios où le gain de temps est réel, et de ceux où il est absorbé par la revue manuelle et la reprise du code généré.