property-based-testing

property-based-testing スキルの概要

このスキルは何のためにあるか

property-based-testing スキルは、例ベースのテストだけでは十分な安心感が得られなくなったときに、プロパティベーステストの作成・レビュー・改善を支援します。特に、ラウンドトリップ、イミュータブルな不変条件、パーサー、バリデーター、ノーマライザー、ソートロジック、スマートコントラクトの状態ルールを検証したいときに、この property-based-testing スキルは有効です。

どんな人に向いているか

最も相性がいいのは、成熟した PBT ライブラリがある言語で開発しているエンジニア、弱いテストをレビューする人、そして機能を最初からプロパティとして定義したい開発者です。property-based-testing をインストールすべきか判断しているなら、見るべきポイントは、そのコードに再利用できる構造、可逆な変換、多数の入力に対して成立すべきルールがあるかどうかです。

何が違うのか

一般的なテスト用プロンプトと違い、このスキルは、検出、プロパティの選定、ストラテジー設計、失敗の解釈を軸に整理されています。ここで重要なのは、導入の最大の障壁が構文ではなく、有用なプロパティの見極めと、過度なフィルタリングをせずに妥当な入力を生成することだからです。このスキルは property-based-testing for Skill Testing として複数のエコシステムにまたがって使えるほど広く、スマートコントラクトにも対応できます。

property-based-testing スキルの使い方

まずインストールして、適切なコンテキストを読み込む

npx skills add trailofbits/skills --skill property-based-testing でインストールし、最初に SKILL.md を開いてください。判断を早めたい場合は README.md も読み、作業内容に最も関係する参照ファイルとして references/generating.md、references/reviewing.md、references/interpreting-failures.md も確認してください。

曖昧な意図を使えるプロンプトに変える

良い property-based-testing usage プロンプトでは、対象、操作、重視する保証をはっきり書くべきです。より良い入力例: “この serializer に decode(encode(x)) の PBT を追加し、入力は有効な UTF-8 とサイズ制約内に収めること。” より悪い入力例: “このモジュールのプロパティテストを書いて。” 前者なら、スキルに具体的なプロパティ、有効なドメイン境界、期待する出力の形が伝わります。

リクエストに含めるべき情報

言語、テストライブラリ、関数シグネチャ、既知の不変条件、無効入力時の挙動、例や仕様を含めてください。property-based-testing ガイドをレビュー用途で使うなら、現在のテストを貼り、バグ検出、リファクタリング、品質監査のどれを狙っているかも明記してください。コードにパースやバリデーションの経路があるなら、壊れたデータでどう振る舞うべきかを書いてください。そうしないと、曖昧なテストや不適切な assume() の使い方につながります。

推奨ワークフロー

まずコードをプロパティの種類に当てはめます。ラウンドトリップ、冪等性、不変条件、順序、オラクルのどれかです。次に、厳しいフィルタリングに頼らず、構成によって妥当な入力を生成する strategy を設計します。最後に、失敗をバグ扱いする前に references/interpreting-failures.md で解釈します。スマートコントラクトでは、EVM 向けの注意点を確認し、状態モデルを明示的に保ってください。

property-based-testing スキル FAQ

property-based-testing は通常のテストの置き換えですか？

いいえ。このスキルが最も役立つのは、通常の例では境界条件を取りこぼしやすい場合や、1つのプロパティで多くの挙動をまとめて表現できる場合です。局所的な回帰には例ベースのテストを残し、少数のケースより一般ルールのほうが明確な場面で property-based-testing を使ってください。

この property-based-testing ガイドは初心者向けですか？

はい、対象の挙動が単純で、ラウンドトリップや冪等性の確認のようにプロパティが明快なら初心者にも向いています。仕様が曖昧だと難しくなります。PBT は、ジェネレーターが役立つ前に、まず明確な契約が必要だからです。

いつこのスキルを使うべきではありませんか？

挙動が主に UI 駆動である、非常に非決定的である、または安定したプロパティとして表現できない場合は、最初からこれに頼らないでください。さらに、本番コードをただなぞるだけの長い再実装チェーンしかオラクルがない場合も、相性はよくありません。

自分の言語やフレームワークに合っていますか？

このスキルは、Hypothesis、fast-check、proptest、jqwik、ScalaCheck、FsCheck、StreamData、QuickCheck、そして Echidna や Medusa のようなスマートコントラクト用 fuzzers など、多くのエコシステムをサポートします。もし自分のスタックがこの一覧にない場合でも、考え方自体は十分役立ちますが、テスト構文や strategy API は適宜調整が必要です。

property-based-testing スキルを改善するには

対象だけでなく、最も強いプロパティを伝える

最良の結果は、保証内容を正確に言語化したときに得られます。たとえば、normalize(normalize(x)) == normalize(x) for Unicode strings は “normalize をテストして” より優れています。property-based-testing スキルは、プロパティが具体的で、反証可能で、既知の契約に結びついているほど高い性能を発揮します。

ジェネレーターを左右する制約を共有する

よくある失敗は、無効入力、フィルタリングしすぎた strategy、本当のバグを拾えないほど弱いプロパティです。許容範囲、形式ルール、サイズ制限、例外が期待されるかどうかを明示すると出力品質が上がります。プロパティが検証後にのみ成立すべきなら、その点もはっきり書いてください。

失敗例から反復する

最初のテストが失敗したら、単に修正を求めるだけにしないでください。縮約された counterexample、意図したルール、境界ケースの振る舞いを定義するドキュメントを渡してください。そうすれば、スキルは実際のバグと不適切なプロパティを切り分け、より強い 2 回目のテストやリファクタリング案を出しやすくなります。