workwithai.chat
automatisationFonctionne bien avec ClaudeFonctionne bien avec ChatGPTFonctionne bien avec Copilot

Générer des tests unitaires que vous validez ensuite par rapport à la spécification

Rédiger le cinquième test ennuyeux pour une fonction est exactement le genre de tâche que les développeurs délèguent volontiers — la génération de tests fait partie des principales tâches IA dans l'enquête JetBrains, et les données de Qodo montrent que les développeurs utilisant l'IA pour les tests affichent une confiance bien plus élevée dans leur suite de tests (61 % contre 27 %). Le piège : un test rédigé à partir du seul code se contente d'encoder ce que le code fait déjà, bugs compris.

Prompt
Vous êtes un ingénieur de test expérimenté. Rédigez des tests unitaires pour la fonction que je colle, en suivant le style de test de mon projet.

Langage et framework de test : {{framework}}
La fonction à tester :
{{code}}
Le comportement attendu, dans mes propres mots (la spécification) : {{spec}}

Produisez :
1. Une courte liste des comportements et cas limites à tester, dérivée du comportement attendu — pas seulement de ce que fait le code actuellement. Incluez les valeurs limites, les entrées vides et nulles, les chemins d'erreur, et tout invariant que j'ai décrit.
2. Le code des tests, un test clairement nommé par comportement, en suivant les conventions de {{framework}}.
3. Une note sur tout comportement que vous n'avez pas pu tester parce que la spécification est ambiguë ou qu'une dépendance nécessite un mock.

Règles :
- Là où le comportement réel du code contredit le comportement attendu que j'ai décrit, écrivez un test ÉCHOUANT qui vérifie le comportement attendu et signalez-le — n'ajustez pas le test pour qu'il corresponde à un bug potentiel.
- N'utilisez que le framework, les assertions et les outils de mock standards de {{framework}} ; n'importez pas de paquets ou d'utilitaires dont vous n'êtes pas certain de l'existence.
- Ne faites pas d'assertions sur des éléments internes privés ou des chaînes de log exactes, ce qui rendrait les tests fragiles.

Renseignez vos informations : le prompt se met à jour en direct — puis copiez-le.

Ce que vous obtenez (extrait)

Comportements à tester : remise normale appliquée ; remise plafonnée pour que le prix ne soit jamais négatif ; prix négatif rejeté ; client null géré ; commande de quantité nulle. # pytest def test_applies_percentage_discount(): assert final_price(100, 0.2) == 80 def test_rejects_negative_price(): with pytest.raises(ValueError): final_price(-1, 0.2) Remarque : votre spécification indique que le prix ne doit jamais devenir négatif, mais le code retourne une valeur négative pour des remises supérieures à 100 %. J'ai écrit test_price_never_negative comme un test ÉCHOUANT vérifiant le comportement attendu. Impossible de tester l'arrondi monétaire — la spécification ne le définissait pas.

Le flux de travail complet

  1. Notez d'abord vous-même le comportement attendu — la spécification, pas seulement ce que fait le code
  2. Générez les tests, puis relisez chacun d'eux et vérifiez qu'il valide bien ce que vous voulez réellement
  3. Exécutez la suite ; examinez tout échec comme un bug potentiel réel, pas comme un test à faire taire
  4. Ajoutez les cas manqués par le modèle et supprimez ceux qui sont fragiles ou redondants

Attention à

Les tests générés à partir du seul code réussissent par construction et ne prouvent rien — ils figent le comportement actuel, bugs compris. Fournissez le comportement attendu séparément et vérifiez que tout test échouant pointe vers un défaut réel.

Vérifiez que toute bibliothèque ou tout utilitaire de test importé par le modèle existe réellement. Des études ont montré qu'environ un package suggéré par l'IA sur cinq est halluciné, et des attaquants déposent ces noms sous forme de logiciels malveillants (une technique de chaîne d'approvisionnement appelée slopsquatting) — n'ajoutez jamais de dépendances suggérées par l'IA sans les vérifier.

Gardez le code propriétaire et les vraies données clients hors des outils IA grand public — utilisez des données de test fictives, ou une offre entreprise avec entraînement désactivé.

D’où ça vient

Chaque cas d’usage de ce site s’appuie sur des témoignages réels rapportés par les développeurs en exercice — rien n’est inventé par nous.

Plus de cas d’usage de l’IA pour les développeurs

analyse

Faire expliquer un code inconnu avant de le modifier

analyse

Une première relecture de votre diff avant qu'un humain ne le voie

analyse

Déboguer avec la méthode du canard en plastique un problème qui vous résiste

rédaction

Transformer une décision en ADR ou dans la documentation que vous aviez sautée

communication

Rédiger des messages de commit et des descriptions de PR à partir de votre diff

← Les 6 cas d’usage : comment les développeurs utilisent l’IA