Comment j'écris d'abord des tests avec GitHub Copilot (sans me mentir)
Le développement piloté par les tests échoue car l’écriture de tests est plus lente que l’écriture de code. Copilot renverse les calculs, et c'est dans ce flux de travail qu'il fonctionne véritablement.
Chaque développeur croit aux tests de la même manière que tout le monde croit au fil dentaire, et le développement axé sur les tests échoue pour la même raison : lorsque vous êtes en flux, écrire des tests, c'est comme s'arrêter pour faire de la paperasse. Copilot a changé les calculs pour moi, non pas en rendant les tests agréables mais en les rendant suffisamment rapides pour que l'objection administrative disparaisse. C’est le flux de travail là où il tient réellement le coup.
L'astuce consiste à écrire le test en tant que spécification et à laisser Copilot faire le passe-partout. Avant d'aborder l'implémentation, j'écris un test d'échec avec le scénario dans le nom du test et un commentaire décrivant le comportement attendu en langage clair. Copilot remplit les assertions, les moqueries et la configuration avec une compétence surprenante, car les fichiers de test sont exactement le type de code structuré dans lequel il excelle. Mon travail se résume à vérifier si le test teste la bonne chose, ce qui relève du jugement et non de la saisie.
Regroupez les scénarios, une fonction à la fois. Je liste les cas avant de commencer, le chemin heureux, l'entrée vide, la limite, l'erreur, puis je demande à Copilot de les générer en un seul passage et de revoir l'ensemble ensemble. L'examen de cinq tests dans leur ensemble permet de détecter ce qui manque en les examinant un par un : le cas manquant, généralement celui qui est étrange par lequel votre base de code a été mordue auparavant. Mon invite de pré-vol comprend désormais une ligne de commentaires répertoriant les incidents de production passés dans ce module, car le modèle ne peut pas connaître ce contexte à moins que vous ne le lui disiez.
La partie honnête du test d’abord avec l’IA est de savoir où elle induit en erreur. Copilot se fera un plaisir d'écrire un test qui reflète vos fausses hypothèses, et une suite verte construite sur des malentendus partagés est pire que pas de suite, car elle défend le bug. L'antidote est bon marché et non négociable : avant de l'implémenter, exécutez le test et observez-le échouer pour la bonne raison, puis interrompez délibérément le résultat attendu dans l'assertion et confirmez que le test le détecte. Trente secondes par test qui maintiennent la suite honnête.
Ce que cela m'a apporté en pratique : une couverture sur les chemins ennuyeux, la validation des entrées et la gestion des erreurs, que je n'avais jamais l'habitude d'écrire, car le coût est tombé à près de zéro. Ce que cela ne m'a pas acheté : une excuse pour ne pas réfléchir à ce que le code devrait faire, et c'est là que le test d'abord était toujours censé aider de toute façon. Le rythme rouge-vert-refactor survit intact ; Copilot vient de supprimer la partie où écrire le test rouge ressemblait à une taxe.