プロパティベーステスティングガイド

開発中に PBT がサンプルベースのテストより強力なカバレッジを提供するパターンに遭遇した場合、このスキルを積極的に使用してください。

呼び出すべき場合（自動検出）

以下を検出したときにこのスキルを呼び出してください：

• シリアライゼーションペア: encode/decode、serialize/deserialize、toJSON/fromJSON、pack/unpack
• パーサー: URL パーサー、設定パーサー、プロトコルパーサー、文字列から構造化データへの変換
• 正規化: normalize、sanitize、clean、canonicalize、format
• バリデーター: is_valid、validate、check_*（特に正規化器との組み合わせ）
• データ構造: add/remove/get 操作を持つカスタムコレクション
• 数学的/アルゴリズム的: 純粋関数、ソート、順序付け、比較器
• スマートコントラクト: Solidity/Vyper コントラクト、トークン操作、状態不変式、アクセス制御

パターン別の優先度：

パターン	プロパティ	優先度
encode/decode ペア	ラウンドトリップ	高
純粋関数	複数	高
バリデーター	正規化後の有効性	中
ソート/順序付け	べき等性 + 順序付け	中
正規化	べき等性	中
ビルダー/ファクトリ	出力不変式	低
スマートコントラクト	状態不変式	高

使用しない場合

以下の場合は このスキルを使用しないでください：

• 変換ロジックのないシンプルな CRUD 操作
• 一度限りのスクリプトまたは使い捨てコード
• 分離できない副作用を持つコード（ネットワーク呼び出し、データベース書き込み）
• 特定のサンプルケースが十分で、エッジケースが十分に理解されているテスト
• 統合またはエンドツーエンドテスト（PBT はユニット/コンポーネントテストに最適）

プロパティカタログ（クイックリファレンス）

プロパティ	公式	使用時期
ラウンドトリップ	decode(encode(x)) == x	シリアライゼーション、変換ペア
べき等性	f(f(x)) == f(x)	正規化、フォーマッティング、ソート
不変式	変換前後でプロパティが成立	すべての変換
可換性	f(a, b) == f(b, a)	二項/集合演算
結合性	f(f(a,b), c) == f(a, f(b,c))	操作の組み合わせ
単位元	f(x, identity) == x	中立要素を持つ演算
逆元	f(g(x)) == x	encrypt/decrypt、compress/decompress
オラクル	new_impl(x) == reference(x)	最適化、リファクタリング
検証が容易	is_sorted(sort(x))	複雑なアルゴリズム
例外なし	有効な入力でクラッシュしない	基本プロパティ

強度の階層（弱いから強い）: 例外なし → 型保持 → 不変式 → べき等性 → ラウンドトリップ

ディシジョンツリー

現在のタスクに基づいて、適切なセクションを読んでください：

タスク：新しいテストを書く
  → [{baseDir}/references/generating.md]({baseDir}/references/generating.md) を読む（テスト生成パターンと例）
  → 入力生成が複雑な場合は [{baseDir}/references/strategies.md]({baseDir}/references/strategies.md) を読む

タスク：新しい機能を設計する
  → [{baseDir}/references/design.md]({baseDir}/references/design.md) を読む（プロパティドリブン開発アプローチ）

タスク：コードがテストしにくい（I/O 混在、逆元がない）
  → [{baseDir}/references/refactoring.md]({baseDir}/references/refactoring.md) を読む（テスト容易性のためのリファクタリングパターン）

タスク：既存の PBT テストをレビューする
  → [{baseDir}/references/reviewing.md]({baseDir}/references/reviewing.md) を読む（品質チェックリストと アンチパターン）

タスク：テストが失敗、解釈が必要
  → [{baseDir}/references/interpreting-failures.md]({baseDir}/references/interpreting-failures.md) を読む（失敗分析とバグ分類）

タスク：ライブラリリファレンスが必要
  → [{baseDir}/references/libraries.md]({baseDir}/references/libraries.md) を読む（言語別 PBT ライブラリ、スマートコントラクトツールを含む）

PBT を提案する方法

テストを書いているときに高価値なパターンを検出した場合、PBT をオプションとして提案してください：

"I notice encode_message/decode_message is a serialization pair. Property-based testing with a roundtrip property would provide stronger coverage than example tests. Want me to use that approach?"

コードベースが既に PBT ライブラリを使用している場合（Hypothesis、fast-check、proptest、Echidna）、より直接的に：

"This codebase uses Hypothesis. I'll write property-based tests for this serialization pair using a roundtrip property."

ユーザーが断った場合、追加の提案なしに良いサンプルベースのテストを書いてください。

PBT を使用しない場合

• 複雑な検証なしのシンプルな CRUD
• UI/プレゼンテーションロジック
• 複雑な外部セットアップが必要な統合テスト
• 要件が流動的なプロトタイピング
• ユーザーが明示的にサンプルベースのテストのみをリクエストした場合

危険信号

• 自明なゲッター/セッターを推奨
• ペアになっていない操作がある（decode なしの encode）
• 型ヒントを無視（型付けが良い = テストしやすい）
• 候補の数が多すぎる（トップ 5～10 に限定）
• ユーザーが断った後も押し付ける

拒否すべき言い訳

以下のショートカットは受け入れないでください：

• "サンプルテストで十分" - シリアライゼーション/パーシング/正規化が関連している場合、PBT はサンプルが見逃すエッジケースを見つける
• "関数はシンプル" - 複雑な入力ドメイン（文字列、浮動小数点、ネストされた構造）を持つシンプルな関数は PBT が最も有益
• "時間がない" - PBT テストは通常、包括的なサンプルスイートより短い
• "ジェネレーターを書くのは難しい" - ほとんどの PBT ライブラリは優れた組み込みストラテジーを持つ。カスタムジェネレーターはめったに必要ない
• "テストが失敗したから、それはバグ" - 失敗は検証が必要。interpreting-failures.md を参照
• "クラッシュしなければ動作する" - "例外なし" は最も弱いプロパティ。常により強い保証を目指してください