実装計画に「この挙動をテストする」とだけ書いても、実装後レビューで検証漏れがまとまって見つかることがある。特に非同期状態、複数の等価な入力表現、任意項目、複数ロケールやクライアント間の mirror は、正常系の例示だけでは oracle が定まらず、テストが実装を追認する形になりやすい。

設計時は契約項目ごとに、適用する観点だけを選び、期待結果と観測点を先に固定する。

• 状態遷移: 操作前の状態、操作、操作後に変わる状態、変わってはいけない状態を分ける。操作前から成立している条件を postcondition と誤認しない。
• 同等表現: 同じ意味を持つ別構文、alias、表記揺れ、順序違いが同じ結果になるかを決める。
• optional 境界: 欠落、null、空値、未知値、既定値への黙殺を別ケースとして扱う。
• mirror: ロケール、スキーマ、クライアントなど複製面の leaf まで同じ契約になるかを集合や構造で照合する。

各項目は、どのテスト層が、どの fixture と assertion で検知するかへ対応付ける。網羅表を機械的に肥大させるのではなく、契約に関係する軸だけを選ぶ。完成条件は、主要な契約違反を意図的に入れたとき、対応するテストまたは検知器が失敗することまで説明できる状態である。

効果測定ではレビューの指摘を実装バグと設計由来の oracle 欠落に分ける。後者が繰り返し出るならレビュアーを増やすより設計テンプレートを改訂し、初回レビューでの設計起因指摘数と収束ラウンド数が下がるかを見る。レビューは欠落を後から発見する安全網であり、oracle の設計責任を移す場所ではない。