Gains :
- Capacité à produire des tests unitaires, d'intégration et de cas extrêmes avec des assertions significatives avec l'IA
- Possibilité d'extraire systématiquement la couverture des tests, les valeurs limites et les scénarios négatifs avec la prise en charge de l'IA
- Possibilité de vérifier que les tests produits par l'IA vérifient réellement le comportement et ne se contentent pas de répéter le code existant
Les tests sont le mécanisme qui prouve que le logiciel se comporte réellement comme promis. Une bonne suite de tests vous indique en quelques secondes si une modification casse quelque chose et donne à l'ingénieur la liberté d'agir en toute confiance. L'IA accélère la partie la plus fastidieuse et la plus ignorée de la rédaction des tests : la génération d'une multitude de scénarios, de points d'arrêt et de cas négatifs. Mais il y a ici un piège sournois : l'IA peut écrire des tests qui vérifient le comportement actuel (peut-être défectueux) du code, et non son comportement supposé ; ou il peut produire des tests vides qui réussissent toujours, sans rien vérifier. La valeur d'un test n'est pas de savoir s'il réussit, mais s'il vérifie la bonne chose et devient rouge lorsqu'il est faux.
Dans cette unité, vous apprendrez à produire des tests unitaires, d'intégration et de cas extrêmes avec des assertions significatives ; comment extraire systématiquement la couverture des tests, les points d'arrêt et les scénarios de baisse ; et nous verrons comment vérifier que les tests produits par l'IA valident réellement le comportement.
Concepts : Tests unitaires : teste une seule fonction/classe de manière isolée. Tests d'intégration : teste que plusieurs parties fonctionnent correctement ensemble. Assert : une instruction qui vérifie qu'un résultat est égal à ce qui était attendu ; C'est le cœur du test. Couverture : quelle partie du code est exécutée par des tests ; Une couverture élevée ne garantit pas la qualité.
Produire des tests significatifs
Un bon test fait clairement trois choses : il établit un état, il exécute une action, il affirme le résultat. Lors de l'impression de tests sur l'IA, spécifiez le comportement que vous souhaitez vérifier et les scénarios qu'il doit couvrir ; Sinon, cela produit des tests superficiels qui réussissent toujours.
- Définir le comportement à tester. "Qu'est-ce qui compte comme n'est-ce pas?" Répondez clairement à la question.
- Demandez des types de scénarios. Condition normale, limite, négative, erreur.
- Importez des assertions significatives. Il n'a pas seulement "généré une erreur", il "a renvoyé la valeur correcte".
- Vérifiez l'exactitude du test. Le test devient-il rouge lorsque vous cassez le code consciemment ?
Invite de génération de test complète : "Écrivez des tests unitaires pour la fonction suivante 'applydiscount(montant, coupon)'. Ayez AU MOINS un scénario dans les catégories suivantes : (1) coupon valide normal, (2) points d'arrêt (montant 0, remise de 100 %), (3) négatif (coupon invalide, montant négatif), (4) cas d'erreur (coupon nul). Affirmez la valeur attendue CONCRÈTE dans chaque test (pas seulement « travaillé »). Nommez les tests de manière lisible. Code : [code]"
Invite d'extraction de valeur limite : "Effectuez une analyse de valeur limite pour les entrées de cette fonction. Pour chaque paramètre, extrayez les valeurs "juste à la limite", "juste en dessous de la limite", "juste au-dessus de la limite" sous forme de tableau. Répertoriez ensuite les scénarios de test qui couvrent ces limites. N'écrivez pas encore de code, juste une analyse et une liste de scénarios. Fonction : [signature]"
Attention : une couverture de test élevée (par exemple 90 %) ne prouve pas que le code est correct. La couverture mesure le nombre de lignes exécutées ; non pas que ces lignes produisent le résultat correct. Un test sans assertion significative augmente la couverture mais ne garantit rien. Le contenu de l'assertion détermine la qualité et non le nombre d'assertions.
Tester le test lui-même : la logique de la mutation
Le moyen le plus pratique de comprendre si le test généré par l’IA fonctionne réellement est de casser délibérément le code (logique du test de mutation). Inversez une condition, faites un signe + - ; Si aucun test ne devient rouge, vos tests ne conservent pas réellement ce comportement.
Invite de recherche de vulnérabilités de test : "Dites-moi quels bogues potentiels dans ce code les tests suivants NE PEUVENT PAS détecter. Suggérez 5 petites mutations qui pourraient être apportées au code (par exemple >= au lieu de >, - au lieu de +) et indiquez pour chacune si les tests existants les détecteraient. Pour ceux qui ne sont pas détectés, suggérez des tests qui devraient être ajoutés. Code : [code] Tests : [test]"
Invite faible/Invite forte
FAIBLE : "Écrivez un test pour cette fonction." (Résultat : généralement un scénario heureux, assertion faible ; erreurs manquées.) FORT : "Écrivez un test pour cette fonction 'passwordStrong'. Règle : au moins 8 caractères, 1 lettre majuscule, 1 chiffre requis. Couvrez les scénarios suivants en tant que tests SÉPARÉS : exactement 8 caractères (limite), 7 caractères (en dessous de la limite), pas de lettres majuscules, pas de chiffres, chaîne vide, seulement des espaces, trop long (1000 caractères) Affirmer explicitement ce qui est attendu valeur vrai/faux dans chaque test et nommez le test en fonction de ce qu'il vérifie."
Une invite puissante donne des règles et des scénarios de limites complètes. Les paires de limites comme "exactement 8/7 caractères" sont les endroits les plus courants où faire des erreurs (en confondant > avec >=). Une invite faible contourne ces limites et transmet l'erreur à la production.
Types de tests et où les utiliser
Type d'essai
Qu'est-ce que cela confirme ?
Contribution de l'IA
Attention
unité
Fonction/classe unique
Génère rapidement plusieurs scénarios
Une affirmation significative est requise
intégration
Pièces travaillant ensemble
Scénario et projet de données fictives
Véritable comportement addictif
terminer/accepter
Flux d'utilisateurs complet
Liste des étapes et attentes
sujet à la fragilité
régression
Ancienne erreur qui ne revient pas
Tests spécifiques aux défauts
Doit être ajouté à chaque correctif
Mini-étuis
Cas 1 — Le test qui réussit toujours. L'IA écrit 12 tests sur une fonction et ils réussissent tous. L'ingénieur devient méfiant et déforme délibérément la valeur de retour de la fonction ; Seuls 3 des tests deviennent rouges. Les 9 autres tests ne contiennent pas d'affirmations significatives. Les tests sont renforcés par la chasse aux mutations ; une véritable protection est obtenue dans 9 scénarios.
Cas 2 — Erreur de limite. Une fonction de vérification de l'âge devrait indiquer « 18 ans et plus est valide », mais > 18 est écrit, ce qui signifie que 18 ans est rejeté. L'erreur apparaît immédiatement lors des tests car l'IA génère le scénario « exactement 18 » grâce à l'analyse des points d'arrêt. Un test de limite unique évite toute véritable plainte des utilisateurs.
Cas 3 — Correction du comportement actuel. Lorsqu'on demande à l'IA "d'écrire un test basé sur ce code", elle produit un test qui accepte comme "correcte" une erreur d'arrondi qui existe déjà dans le code. Lorsque l'ingénieur imprime le test conformément aux exigences (valeur correcte attendue) et non au code, le test devient rouge et la véritable erreur se produit. Les tests doivent être dérivés des attentes et non du code.
Erreurs courantes
- Affirmation inutile. "Je n'ai pas généré d'erreur" ne suffit pas ; La valeur correcte doit être vérifiée.
- Confondre portée et qualité. Une couverture élevée ne garantit pas des résultats précis.
- Impression du test par code. Corrige l'erreur actuelle sur « true » ; Les tests doivent découler des attentes.
- Sauter les valeurs limites. Confondre > avec >= est l'erreur la plus courante ; les paires de limites doivent être testées.
- Ne pas auditer le test lui-même. Un test qui ne devient pas rouge lorsque vous cassez le code n’offre pas de protection.
En résumé
Une bonne suite de tests est la clé pour apporter des modifications en toute confiance. L'IA génère rapidement une multitude de scénarios, de limites et de situations négatives ; Mais s’il dérive les tests du code plutôt que des exigences, il peut corriger les bogues existants ou écrire des tests dénués de sens qui réussissent toujours. Affirmez la valeur concrète attendue dans chaque test, incluez des paires liées et vérifiez que vos tests protègent réellement en cassant délibérément le code. Le contenu de l'assertion, et non le nombre de portées, détermine la qualité.
Tâche de candidature
Sélectionnez une fonction et demandez-lui de générer des tests dans quatre catégories (normal, limite, négatif, erreur) avec une invite de génération de tests complète ; Faire affirmer la valeur concrète attendue dans chaque test. Ensuite, exécutez l'invite de recherche de vulnérabilités de test, suggérez 5 petites mutations dans le code et exécutez les tests pour vérifier celles qu'elles détectent. Ajoutez un nouveau test pour au moins une mutation qui n’a pas été détectée et montrez qu’elle est désormais dans le rouge.
liste de contrôle
- [ ] J'ai imprimé les tests en fonction du comportement attendu/correct, pas du code.
- [ ] J'ai couvert les scénarios normaux, limites, négatifs et d'erreur.
- [ ] J'ai affirmé la valeur concrète attendue dans chaque test.
- [ ] J'ai testé des paires de bordures (juste au-dessus-en-dessous / juste au-dessus-en-dessous).
- [ ] En cassant volontairement le code, j'ai confirmé que les tests devenaient rouges.
- [ ] J'ai ajouté un nouveau test pour les mutations non détectées.