この記事で扱うこと
コード生成ツールにフロントエンドの作業を任せる流れを整理しながら、要件が実装の途中でこっそり変わる問題と、「テストが通りました」が実は偽の緑である問題を、どんな構造で防げるかを見た。特定のツールや製品ではなく、どこでも適用できる判定基準の設計原則だけを残す。
同じ日に以前調査したテキストアンカー復元のロジックも整理したのだが、二つの主題が思いがけず同じ原則に収束した。
先に知っておく概念
オラクル（oracle） は実行結果が正しいかどうかを判定する基準である。試験の解答用紙にあたり、答案（コード）をいくら睨んでも採点はできない。ポリシー出所（policy source） は「何が正解か」を決める資格のある場所を指す。VALID_RED は新しく書いたテストが意図したその理由で失敗している状態を指し、誤字や設定の問題で赤いのを本当の失敗と取り違えると、見当違いの箇所を直すことになる。
正解を決める権限を制限する
最も印象的な設計は、正解を決められる場所を利用者の明示的な回答と承認済みの仕様文書の二つだけに限定したことだ。プロダクトコード、既存のテスト、ブラウザで観察した挙動、レビュアーの意見はすべて調査資料へ格下げされる。
反例を見ると意味が明確になる。ツールは既存コードを読めるので「今こう動くのだから、これが要件だろう」と推論しやすく、その瞬間にバグが仕様へ昇格する。実装と要件が食い違ったらコードに合わせず止まって確認を求める、というルール一つでこの失敗モードの大半を防げる。
基準は「この状況でこうすればこの結果になるべきで、これは決して起きてはならない」を一行ずつ書いた表にする。出典を付けられない行は慣例で埋めず未決のままにする。
合意はテキストで固定しハッシュで検証する
会話だけで決めた要件は、長い作業のなかで必ずぼやける。基準の表をファイルとして保存し内容ハッシュを記録しておけば、ぼやけたという事実を人より先にツールが検知する。
ここに重要なルールが一つ付く。ハッシュが合わないからといって再度固定して通すことはしない。 それまでに集めた証拠を捨て、人の決定を待つ状態へ戻る。検証を通すために検証基準を変えれば、それはもう検証ではない。
偽の緑に名前を付けて禁止する
「通りました」を作る抜け道は数えるほどしかない。assertion を緩める、失敗するテストをスキップへ変える、任意の待ち時間を入れてタイミング問題を覆い隠す。この三つを明示的な禁止事項として書いておくほうが、「手を抜かないでください」よりはるかによく守られた。
より根本的な仕掛けは完了の定義を動かすことである。テスト通過が完了なら通すことが目的になり、そこから assertion が痩せていく。ブラウザで実際に操作した証拠と独立したレビューまで終えて完了と定義すれば、緩める利点そのものが消える。
テストが本当に欠陥を捕まえるかを機械的に確かめたいなら、コードをわざと少し壊してみる方法がある。
確信が足りなければ止まる
同じ日に以前の調査記録を整理していて、興味深い対称性に気づいた。ウェブ文書のハイライトを復元するとき、候補区間のスコアを付けたうえで1 位と 2 位の差が小さければ候補があっても付けないというルールがあった。しきい値を超えたかとは別に、競合状況そのものを見る指標である。
これは先の「ポリシーが未決なら進めずに止まる」とまったく同じ判断だ。一方は人へ質問を返し、もう一方はハイライトを諦めるが、どちらも静かに誤った結果を作らないという目的を持つ。見当違いの場所に付くほうが付かないより悪い、という原則が数字に翻訳されたわけである。
終了コード 0 を信じない
副次的にもう一つ学んだ。ノートを作るコマンドが終了コード 0・出力なしで終わったのに、肝心のファイルができていなかった。終了コード 0 は「成功した」ではなく**「エラーを報告しなかった」** という意味である。ファイル生成のように副作用が目的のコマンドは、副作用そのものを確認する必要がある。