Quand j'ai commencé ce projet et qu'il était encore une petite base de code, je savais que les tests unitaires seraient importants, mais comme beaucoup de développeurs, j'ai mis cela de côté après avoir construit la première suite de tests en faveur de la construction des fonctionnalités principales.
Quand j'ai commencé ce projet et qu'il était encore une petite base de code, je savais que les tests unitaires seraient importants, mais comme beaucoup de développeurs, j'ai mis cela de côté après avoir construit la première suite de tests en faveur de la construction des fonctionnalités principales. Mon objectif principal au début était de faire fonctionner la logique middleware — la pièce maîtresse de l'application — et de donner vie au Produit Minimum Viable (MVP). Cela signifiait omettre une bonne partie de la couverture de tests au nom du progrès.
Une fois que le MVP fonctionnait, j'ai reporté mon attention sur les tests. En regardant le projet, j'estimais au moins une semaine ou deux d'écriture de tests, selon la complexité de chaque composant. Certains seraient simples. D'autres — surtout là où des cas limites ou une logique de branchement complexe étaient impliqués — seraient beaucoup plus chronophages.
À ce moment-là, je me suis tourné vers l'IA. J'utilisais un "CoPilot" pour aider à écrire du code, et j'ai pensé qu'il pourrait aussi aider avec les tests.
Au début, j'ai demandé à l'IA d'« écrire des tests unitaires » sans vraiment de contexte ni de contraintes. Le résultat ? Un désastre. Les tests ne fonctionnaient pas, ils faisaient des suppositions incorrectes sur le code, et tout l'effort s'est transformé en boucle de code de test cassé et de réécriture frustrante. L'IA a généré beaucoup de code — mais pas le genre que je pouvais utiliser sans refactorisation sérieuse.
La percée est venue quand j'ai changé mon approche. Au lieu de traiter l'IA comme un magicien, j'ai commencé à l'utiliser plus comme un développeur junior. Je lui donnais un fichier à la fois, expliquais l'intention du code, et lui disais de se concentrer sur l'écriture de tests précis et fonctionnels pour ce fichier seulement.
Cela a tout changé.
Soudain, les tests étaient plus faciles à implémenter pour l'IA. Ils étaient correctement délimités, alignés avec la logique réelle, et ne nécessitaient pas des heures de débogage. Mon IA a travaillé fichier par fichier, écrivant et exécutant des tests.
En moins d'une journée, la couverture de tests est passée de 5% à plus de 96%.
Des tests qui auraient pris des jours à écrire ont été complétés en heures, et la tranquillité d'esprit qui vient avec une couverture de test presque complète ? Inestimable.
Je suis passé d'une Suite de Tests et 5 tests à :
Que vous lanciez un nouveau projet ou que vous essayiez de combler les tests sur un ancien, l'IA peut être un énorme gain de temps — si vous l'utilisez bien.
Utilisez-vous l'IA pour écrire des tests dans vos projets ? Quelle a été votre expérience ?