仕様化テスト（characterization test）は、既存のコードがどう振る舞うべきかを主張するのではなく、実際にどう振る舞っているかを記録するテストである。和田卓人はこの対比を「As-Is」対「To-Be」として描く。テスト駆動開発に必要なのは、プログラムやシステムが何をすべきかを検証する To-Be のテストだが、レガシーコードではその意図が失われていることが多い。仕様書が存在しないこともあれば、コードから大きく乖離してしまっていることもある。そうした状況で To-Be のテストをゼロから書くのは道のりが長すぎるため、ゴールをより手前に置く。まず、コードがいまどう動いているかを捉えるのである。
用法
和田は、生成 AI がこの作業に極めて効果的だと報告しており、その理由を依頼の形に見いだしている。既存のコードの振る舞いを別の角度から捉えて自動テストとして表現するようモデルに頼むことは、コンテキストを絞って与えられる事後的なタスクである。これは、システムがどう振る舞うべきかを決めることとは異なる。後者について彼は、人間がスキルを積み上げることによって、あるいはソフトウェア考古学として過去の意思決定を掘り起こすことによってたどり着かなければならないと述べている。
安井力は、同じテストが求められる 2 つ目の場面を挙げている。開発が終わった後の運用保守フェーズであり、チームが現在の振る舞いを捉え、それが壊れたときに知らせてもらう必要がある場面である。彼は、保守チームは開発チームよりかなり小さいこと、そして保守作業に長けた人が必ずしもテストコードを書くことに習熟しているわけではないことを指摘しており、それがこの場面で AI の支援を価値あるものにしている。
適用される場面
テストカバレッジがなく、意図された振る舞いについての信頼できる説明もない場合に適用される。和田の主張は、As-Is のテストがあるだけでも、機能追加によって持ち込まれた欠陥や振る舞いの変化を検知できるようになり、何もない状態に比べれば大きな前進だということである。そして、それ以上のことをする余力のない組織にとっては、カバレッジを引き上げる道具としての価値だけでもすでに相当なものだという。
その限界は、何を捉えるかにある。仕様化テストが記録するのはコードがいまどう動いているかだけであり、システムが何をすべきかはそこに含まれない。和田の説明によれば、それは人間がそれを決めるスキルを積み上げることによって、あるいはソフトウェア考古学として過去の意思決定を掘り起こすことによってもたらされなければならない。彼は、To-Be のテストが依然として理想であり、これはその代わりではなく、より手前のゴールであると明言している。