Gains :
- Capacité à produire des tests unitaires, des cas extrêmes et des analyses des écarts de couverture avec l'IA
- Possibilité d'imprimer les attentes des tests en fonction de la spécification, et non du comportement actuel du code
- Possibilité de tester si un test protège réellement en injectant des erreurs
L'écriture de tests est l'une des tâches les plus génératrices de valeur que la plupart des développeurs retardent. Une bonne suite de tests est la preuve que le code fonctionne comme prévu et constitue une bouée de sauvetage pour les modifications futures. Le problème est que l’écriture de tests est répétitive et prend du temps – exactement le genre de travail dans lequel l’IA brille. Mais il y a un hic : l’IA teste souvent le comportement existant du code, et non le comportement qu’il devrait être. La gestion de cette différence est l’essence même de cette unité.
Dans cette unité, vous apprendrez les tests unitaires (tests qui testent une fonction seule, de manière isolée), les tests de cas extrêmes et la génération de données de test avec l'IA ; combler les lacunes dans la couverture des tests ; et pourquoi il est dangereux de faire aveuglément confiance aux tests d’IA.
Les deux côtés des tests : corriger le comportement ou vérifier
Un test peut servir à deux fins différentes. La première est la vérification : elle teste que le code est correct, qu'il est conforme à la spécification. La seconde est la protection contre la régression : elle gèle le comportement du code aujourd'hui, donc si quelqu'un le modifie accidentellement demain, le test sera interrompu et avertira.
L’IA est très bonne dans ce dernier domaine ; Il examine le code et génère des cas qui testent « ce qu'il fait actuellement ». Mais si le code est erroné dès le départ, l’IA peut qualifier ce mauvais comportement de « correct ». Vous devez donc revoir l'assertion de chaque test produit par l'IA : « Le code renvoie 42 et le test attend 42 » ne signifie pas que 42 est la bonne réponse.
Attention : Si l'IA réussit le test, cela ne signifie pas que le code « fonctionne » ; cela signifie simplement "il se comporte comme l'IA l'attend". Vous décidez si l’attente est correcte ou non en examinant la spécification.
Étape par étape : rédiger des tests robustes avec l'IA
- Donnez la spécification, pas seulement le code. Si vous ajoutez l'information « Cette fonction devrait faire cela », l'IA peut écrire l'attente correcte ; Il testera le comportement actuel si vous fournissez simplement le code.
- Demandez des cas extrêmes. Vide, nul, zéro, négatif, trop grand, mauvais format, concurrence – revendiquez explicitement le chemin du bonheur.
- Spécifiez le cadre et le style de test. "utiliser pytest", "modèle Arrange-Act-Assert", "laisser chaque test tester une chose", etc.
- Vérifiez les attentes (affirmation). Comparez avec la spécification selon laquelle chaque assertion vérifie la valeur correcte.
- Combler les lacunes dans la portée. Donnez les tests existants et demandez « quelles branches et quels cas n'ont pas été testés ? vous fait demander; puis vérifier les tests complémentaires produits.
Trois mini-étuis
Cas 1 — Couverture de 52 % à 85 %. La couverture des tests d'un module de service était de 52 %. L’équipe a transmis les tests existants à l’IA, lui a demandé de répertorier les branches non testées et de générer des tests pour elles. Avec un examen humain, la couverture est passée à 85 % ; Au cours du processus, l'IA a découvert un véritable bug (un chemin qui renvoyait le mauvais code d'erreur) dans une branche de bug qui n'avait jamais été testée auparavant.
Cas 2 — Le piège de la fixation des fausses attentes. Une fonction d’arrondi de l’argent était en fait erronée ; Au lieu d’arrondir 2,675 à 2,67, il a arrondi 2,67 au lieu de 2,68. L'IA a examiné le code et a écrit assert round_money(2.675) == 2.67 — gelant l'erreur comme « vraie ». Lorsque le développeur a lu la spécification, il a corrigé les attentes et détecté le véritable bug. Tester la règle, et non le code, a fait la différence.
Cas 3 — Explosion de l’état Edge. Lorsque vous demandez à l’IA uniquement des « cas extrêmes » pour une fonction de plage de dates ; Il a produit 8 cas tels que début = fin, intervalle inversé, année bissextile le 29 février, différents fuseaux horaires et intervalle nul. Deux d’entre eux (espacement inversé et année bissextile) étaient en réalité à l’origine de l’erreur. L'examen manuel de ces cas est souvent ignoré ; L’IA est devenue ici un partenaire de « brainstorming de pointe ».
Quatre modèles copiables
Génération de tests basée sur les spécifications :
Rôle : Un développeur qui écrit des tests. Framework : {{pytest/JUnit/Jest...}}.Ce que la fonction DEVRAIT FAIRE (spécification) : {{rule}}Écrivez des tests pour la fonction suivante. Écrivez les attentes conformément à la spécification, PAS à la sortie actuelle du code. Happy path + ajoutez au moins 4 cas extrêmes. Laissez chaque test tester une chose, utilisez un nom descriptif. {{fonction}}
Brainstorming sur les cas extrêmes :
Répertoriez les cas de bord/d'échec qui devraient être essayés lors des tests pour cette fonction (nul, nul, points d'arrêt, mauvais format, concurrence, erreur externe). Pour chaque cas : entrée, comportement attendu. N'écrivez PAS de code pour l'instant, faites simplement une liste.{{function}}
Analyse des écarts de couverture :
Vous trouverez ci-dessous les fonctions et les tests disponibles. Quelles branches, conditions et cas n’ont pas été testés ? Énumérez les lacunes et rédigez de nouveaux tests uniquement pour les lacunes. Ne répétez pas ceux existants. Fonction :{{function}}Tests :{{existing_tests}}
Données de test / génération d'objets fictifs :
Générez des données de test réalistes pour les tests {{function/service}} : échantillons valides, échantillons limites et échantillons invalides séparément. Suggérez un comportement fictif simple pour la dépendance externe {{X}}. Utiliser de véritables données/PII confidentielles ; Générez de fausses données.
Invite faible/Invite forte
Faible : "Écrivez un test pour cette fonction."
Strong : "avec pytest. Fonction apply_discount(total, percent) — règle : la remise doit être comprise entre 0 % et 30 %, les limites doivent générer une erreur ValueError, le résultat doit être arrondi à 2 décimales. Écrivez les attentes selon cette RÈGLE (et non par code). Chemin heureux + ces cas extrêmes : 0 %, 30 %, 31 % (erreur), négatif, total = 0. [code]"
Il donne la règle de version forte et dit « écrivez l'attente selon la règle, pas le code » ; Cette seule phrase ferme le piège de l’IA qui corrige les mauvais comportements.
Type d'essai
Contribution de l'IA
contrôle humain
Bons tests unitaires sur route
squelette rapide
L'attente est-elle correcte ?
Cas extrêmes
Un brainstorming approfondi
Éliminer ce qui n'est pas pertinent
Combler les lacunes du champ d'application
Recherche les branches ignorées
Confirmer la signification
Données de test/simulation
Produit un échantillon réaliste
Pas de PII, contrôle du réalisme
Les tests gèrent la qualité, ne la garantissent pas
Une couverture de test élevée donne confiance, mais elle peut aussi être trompeuse : une couverture de 100 % signifie « chaque ligne a été exécutée », et non « chaque ligne est correcte ». Il est facile d’augmenter la couverture grâce à l’IA ; La vraie valeur réside dans la rédaction d’attentes significatives. La valeur d'un test est sa capacité à casser et à vous alerter lorsque le code est cassé. C'est pourquoi les tests générés par l'IA sont basés sur la question « le code se casse-t-il vraiment lorsqu'il change ? Testez-le avec la question ; Rompre délibérément une ligne et voir le test se briser (idée de mutation) est la preuve que le test a fonctionné.
Astuce : Pour voir si un test écrit par l'IA fonctionne, créez un petit bug dans le code (par exemple, remplacez un + par un -) et voyez si le test échoue. S'il ne se brise pas, ce test ne vous protège pas.
Erreurs courantes
- Demander un test sans donner la règle. Le modèle fige le comportement actuel ; corrige l'erreur comme "vrai".
- Accepter les attentes sans les lire. Les tests sont trompeurs si vous ne vérifiez pas que les assertions recherchent la valeur correcte.
- Je teste juste le chemin du bonheur. Les vraies erreurs vivent en marge ; Demandez explicitement les cas extrêmes.
- Confondre la portée avec le but. Un pourcentage élevé ne garantit pas un comportement correct.
- Créer des données réelles/cachées comme données de test. Les données ou secrets des clients ne doivent pas entrer dans les tests et le stockage ; Générez des données synthétiques.
En résumé
L’IA élimine une grande partie de la charge répétitive liée à l’écriture des tests : elle produit des squelettes rapides, de grandes listes de cas extrêmes et des analyses des écarts de couverture. Mais le point le plus critique concerne les attentes : l’IA a tendance à tester le comportement actuel du code, alors que les tests doivent être écrits conformément à la spécification. Donnez la règle, vérifiez les attentes, appliquez les cas extrêmes et testez si les tests protègent réellement en injectant un bug. La couverture des tests est un outil, pas un objectif.
Tâche de candidature
Sélectionnez une fonction et imprimez d'abord un test à l'IA en donnant simplement son code ; Notez les attentes. Imprimez ensuite à nouveau le test, en donnant la spécification (comportement requis) pour la même fonction. Comparez les attentes des deux sets de tests : y en a-t-il des différents, lequel révèle un vrai bug ? Enfin, vérifiez que l'un des tests générés a fonctionné en ajoutant un bug intentionnel au code et en voyant la rupture du test.
liste de contrôle
- [ ] Je distingue si le test consiste à corriger ou à vérifier un comportement.
- [ ] Lorsque je demande un test, je donne la règle (spécification) qui doit être en place, pas le code.
- [ ] Je compare chaque assertion générée à la spécification.
- [ ] Je demande explicitement des cas extrêmes et d'échec.
- [ ] Je considère le pourcentage de couverture comme un outil et non comme un objectif.
- [ ] Je teste si un test protège réellement en injectant des erreurs.