property-based-testing

Vue d’ensemble du skill property-based-testing

À quoi sert ce skill

Le skill property-based-testing vous aide à écrire, relire et améliorer des tests fondés sur des propriétés quand les tests basés sur des exemples ne suffisent plus à vous donner confiance. Il est particulièrement utile pour le skill property-based-testing lorsque vous devez valider des allers-retours, des invariants, des parseurs, des validateurs, des normaliseurs, une logique de tri ou des règles d’état de smart contracts.

Qui en tire le plus de valeur

Meilleur cas d’usage : des ingénieurs qui travaillent dans des langages dotés de bibliothèques PBT matures, des reviewers qui vérifient des tests trop faibles, et des développeurs qui conçoivent des fonctionnalités à spécifier d’abord comme des propriétés. Si vous vous demandez s’il faut installer property-based-testing, la vraie question est de savoir si votre code a une structure réutilisable, des transformations réversibles ou des règles qui doivent rester vraies sur un grand nombre d’entrées.

Ce qui le distingue

Contrairement à un prompt de test générique, ce skill s’organise autour de la détection, du choix de la propriété, de la conception des stratégies et de l’interprétation des échecs. C’est important, car le principal frein à l’adoption n’est pas la syntaxe : c’est de choisir une propriété utile et de générer des entrées valides sans sur-filtrer. Le skill est aussi suffisamment large pour couvrir property-based-testing for Skill Testing dans plusieurs écosystèmes, y compris les smart contracts.

Comment utiliser le skill property-based-testing

Installez-le et chargez le bon contexte

Installez avec npx skills add trailofbits/skills --skill property-based-testing, puis ouvrez d’abord SKILL.md. Pour aller plus vite dans vos décisions, lisez aussi README.md et les fichiers de référence les plus pertinents pour votre tâche : references/generating.md, references/reviewing.md et references/interpreting-failures.md.

Transformer une idée vague en prompt exploitable

Un bon prompt de property-based-testing usage doit nommer la cible, l’opération et la garantie qui vous importe. Meilleure formulation : « Ajoute des PBT pour decode(encode(x)) sur ce sérialiseur, en gardant les entrées dans les limites du UTF-8 valide et des tailles autorisées. » Moins bon : « Écris des tests de propriétés pour ce module. » Le premier donne au skill une vraie propriété, des bornes de domaine valides et une forme de sortie.

Ce qu’il faut fournir dans votre demande

Indiquez le langage, la bibliothèque de test, la signature de la fonction, les invariants connus, le comportement attendu sur les entrées invalides, ainsi que des exemples ou des spécifications si vous en avez. Si vous utilisez le guide property-based-testing pour une revue, collez le test actuel et précisez si vous cherchez à trouver des bugs, à faire un refactoring ou à réaliser un audit de qualité. Si le code comporte des chemins de parsing ou de validation, dites ce qui doit se passer en cas de données malformées ; cela évite les tests vagues et les mauvais usages de assume().

Flux de travail recommandé

Commencez par rattacher le code à un type de propriété : roundtrip, idempotence, invariant, ordre ou oracle. Définissez ensuite des stratégies qui génèrent des entrées valides par construction, plutôt que par un filtrage lourd. Enfin, interprétez les échecs avec references/interpreting-failures.md avant de les traiter comme des bugs. Pour les smart contracts, vérifiez les notes spécifiques à l’EVM et gardez le modèle d’état explicite.

FAQ du skill property-based-testing

property-based-testing remplace-t-il les tests classiques ?

Non. Le skill est surtout précieux là où les exemples ordinaires ratent des cas limites, ou lorsqu’une seule propriété peut couvrir beaucoup de comportements. Gardez les tests d’exemple pour les régressions ciblées et utilisez property-based-testing quand une règle générale est plus claire qu’une poignée de cas.

Ce guide property-based-testing est-il adapté aux débutants ?

Oui, si le comportement cible est simple et que la propriété est évidente, comme un roundtrip ou un contrôle d’idempotence. C’est plus difficile quand la spécification manque de précision, car la PBT a besoin d’un contrat clair avant que le générateur soit vraiment utile.

Quand ne faut-il pas utiliser ce skill ?

N’y recourez pas en priorité lorsque le comportement est surtout piloté par l’interface, très non déterministe ou impossible à formuler comme une propriété stable. C’est aussi un mauvais choix quand le seul oracle disponible est une longue chaîne de réimplémentation qui ne fait que refléter le code de production.

Est-ce compatible avec mon langage ou mon framework ?

Le skill prend en charge de nombreux écosystèmes, notamment Hypothesis, fast-check, proptest, jqwik, ScalaCheck, FsCheck, StreamData, QuickCheck, ainsi que des fuzzers pour smart contracts comme Echidna et Medusa. Si votre stack n’est pas dans cette liste, la méthode sous-jacente reste utile, mais vous devrez peut-être adapter la syntaxe des tests et les API de stratégie.

Comment améliorer le skill property-based-testing

Donnez la propriété la plus forte, pas seulement la cible

Les meilleurs résultats viennent d’une garantie formulée avec précision. Par exemple : « normalize(normalize(x)) == normalize(x) pour des chaînes Unicode » est mieux que « tester normalize ». Le skill property-based-testing fonctionne mieux lorsque la propriété est spécifique, falsifiable et reliée à un contrat connu.

Partagez les contraintes qui façonnent les générateurs

Les échecs les plus courants viennent des entrées invalides, des stratégies trop filtrées et des propriétés trop faibles pour détecter de vrais bugs. Améliorez la qualité du résultat en précisant les plages acceptables, les règles de format, les limites de taille et la présence ou non d’exceptions attendues. Si une propriété ne doit tenir qu’après validation, dites-le explicitement.

Itérez à partir des exemples en échec

Quand le premier test échoue, ne demandez pas seulement une correction. Fournissez le contre-exemple minimisé, la règle attendue et toute documentation qui définit le comportement dans les cas limites. Cela permet au skill de distinguer un vrai bug d’une mauvaise propriété, puis de proposer un test de second passage ou une suggestion de refactorisation plus solide.