AIのRailsレビュー箇所を契約と検証で絞る

契約表はDesign by Contractに基づき、ルールを不変条件・事前条件・事後条件に分けている。不変条件だけでは不十分な具体例も示す。合計が10のままとだけ検証するspecでは、available_stockとreserved_stockが入れ替わるバグが生存した。availableが3減りreservedが3増えるという事後条件を加えるとその変異体は死に、予約数の直前・ちょうど・直後の境界値も加えると在庫モデルは150中62生存から150全殺傷になった。

ツール面ではRubyのミューテーションテスターを直接比較している。mutantのREADMEは無償利用を公開リポジトリに限定し、商用利用には開発者1人あたり月30ドルまたは年250ドルが必要なため、非公開アプリでは避けた。アーカイブ済みのmutestフォークはインストールに失敗した。MITのevilutionを採用し、evilutionもMITのmutineerも2026年に登場したばかりなので採用前にchangelogとissueを確認する価値があると述べている。

レビューの分業は明確だ。品質ゲートが完了条件を満たすか自動で判定し、人間は各specがIDで示す契約行を本当に検証しているか、生存変異体が実際のテスト欠落か、無効化行に真の等価理由があるかだけを確認する。specでのstub利用は、実際のDB状態から到達不可能な失敗と外部APIの2ケースに限定し、それぞれ理由を書くべきだと付け加えている。