Accélérer la génération de tests unitaires et améliorer la qualité du code

Récemment, j'ai eu l'occasion d'approfondir Early, un agent d'IA conçu pour la génération automatique de tests unitaires. En tant que personne travaillant régulièrement avec TypeScript et ExpressoTS Framework, j'avais hâte de voir comment Early pourrait rationaliser mon flux de travail. J'ai décidé de tester l'extension vscode qu'ils ont construite sur ma nouvelle bibliothèque NPM que je développais appelée @expressots/share.

Premières impressions

La première chose qui m'a frappé chez Early était sa capacité à générer automatiquement des tests unitaires pour ma base de code existante. Au lieu de créer des tests à partir de zéro, je pourrais me concentrer sur le raffinement des tests générés et sur l'amélioration de la robustesse et de la testabilité de mon code. Ce changement a considérablement accéléré mon processus de développement. L'autre aspect intéressant que j'ai remarqué est que 83% du code généré, je n'ai fait aucun ajustement, cela a fonctionné immédiatement et a augmenté ma couverture de code. Faites-moi gagner énormément de temps.

Gain de temps et couverture accrue

En seulement 8,5 heures, j'ai réussi à :

• Générez des tests unitaires pour environ 3 000 lignes de code.
• Résolvez les problèmes et améliorez la testabilité du code.
• Obtenez une couverture totale du code de 88 % avec 96 tests.

Le fait que j'ai pu accomplir tout cela en une seule journée était remarquable. Le scénario idéal en matière de test unitaire est de le faire pendant que vous développez réellement vos fonctions. Je l'ai fait après coup, car j'avais déjà une bibliothèque en place, donc quelques ajustements ont été nécessaires pour rendre le code testable.

Résultats positifs

Génération automatique de tests de cas Edge. Par exemple, il a généré des tests unitaires pour des scénarios impliquant des chaînes vides, même lorsque des paramètres étaient requis :

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

Au départ, je n'aurais pas créé de tests pour les chaînes vides dans une fonction aussi simple. Cependant, l'approche d'Early a favorisé des pratiques de programmation défensives, me poussant à gérer des cas extrêmes que j'aurais pu négliger.

Détection des problèmes potentiels

Lors du raffinement des tests générés, j'ai rencontré un problème d'incompatibilité de type :

Problème : jest.fn() renvoie tout, mais process.exit ne renvoie jamais, ce qui entraîne une incompatibilité de type dans TypeScript.
Solution : modifiez la maquette pour qu'elle corresponde à la signature process.exit, en garantissant l'exactitude du type.
Cette découverte m'a incité à ajuster mon code pour une meilleure sécurité des types, en soulignant comment Early peut aider à identifier des problèmes subtils qui autrement pourraient passer inaperçus.

Domaines d’amélioration

Malgré l'expérience globalement positive, j'ai rencontré quelques défis qui, s'ils étaient résolus, pourraient améliorer la convivialité d'Early :

• Compatibilité des versions de la bibliothèque. Tests générés tôt en utilisant des méthodes Jest obsolètes dans certains cas, par exemple :

Utilisation de Jest 29.7

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

// Version corrigée

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

• Options de personnalisation pour la génération de tests Bien que la génération de tests pour les cas extrêmes soit bénéfique, dans certains scénarios, cela peut ne pas être nécessaire :

Observation : générer des tests pour chaque entrée possible, y compris les chaînes vides, peut parfois s'avérer excessif.

Suggestion : introduisez des options pour personnaliser le niveau de génération de tests, permettant aux développeurs d'opter pour des tests de programmation défensifs si nécessaire.

• Améliorations de l'interface utilisateur dans l'extension VSCODE La navigation entre les outils Early et d'autres a mis en évidence certaines limitations de l'interface utilisateur :

Visibilité des résultats des tests : j'ai dû basculer entre Early et Jest pour voir quels tests ont réussi ou échoué.

État de l'arborescence des fichiers : la hiérarchie du projet dans Early s'effondre lorsque je reviens d'autres applications, ce qui m'oblige à rouvrir les dossiers à plusieurs reprises.
Suggestion : améliorez l'interface utilisateur pour afficher les résultats des tests dans Early, en reflétant la structure de Jest. Le maintien de l'état de l'arborescence des fichiers améliorerait également l'expérience utilisateur.

• Moquerie et sécurité des types Le problème avec jest.fn() renvoyant any suggère la nécessité d'une moquerie plus précise :

Observation : l'utilisation de n'importe quel type dans les simulations peut entraîner des incompatibilités de types et potentiellement masquer des bogues.
Suggestion : Affinez la génération de simulation pour utiliser des signatures précises, favorisant ainsi une meilleure sécurité des types et réduisant le besoin de corrections manuelles.

Conclusion

Dans l’ensemble, mon expérience avec Early a été très positive. L'outil a considérablement accéléré mon processus de tests unitaires, me permettant de me concentrer sur l'affinement des tests plutôt que de les écrire à partir de zéro. Cela m'a également encouragé à considérer les cas extrêmes et à améliorer la robustesse de mon code.

Les domaines à améliorer sont relativement mineurs et tournent autour de l'amélioration de la convivialité et de la personnalisation. Résoudre ces problèmes ferait de l’outil un allié encore plus puissant dans le développement de logiciels.

Félicitations à l'équipe Early pour leur excellent travail ! Je suis impatient de voir comment l'outil évolue et je serais heureux de continuer à fournir des commentaires pour aider à l'affiner davantage.