Tests Remain

テストを書かないエンジニアがいた。

手は早かったし、バグも少なかった。テストなんか書かなくても動くものは作れる、と本気で思っていた。あるとき、大規模サービスの複雑なコンポーネントでエッジケースを踏んだ。商用環境で、だ。修正はすぐだった。しかし後始末は最悪だった。影響範囲の特定、破損した全データのリカバリ、顧客への説明、再発防止策の作成。テストがあれば、そのすべてが要らなかった。

テストは面倒だ。書くのに時間がかかるし、メンテナンスも要る。テストコードのほうが本体より多いプロジェクトもある。それでも書く理由は単純で、人間は忘れるからだ。3ヶ月前に自分が書いたコードの意図を、自分でも覚えていない。テストだけがそれを覚えている。

AIがコードを書く時代になって、テストの重要性はむしろ上がったと感じている。

AIの出力は速い。速いが、正しいとは限らない。文脈を読み違えることもあるし、既存のコードとの整合性が取れていないこともある。人間が書いたコードなら「あの人に聞けばわかる」が通用するが、AIが書いたコードには聞く相手がいない。テストだけが、そのコードが意図通りに動いているかを教えてくれる。

膨大なテストがあれば、AIにコードを書かせてもリグレッションを検出できる。テストが通れば出す。落ちたら直す。書いたのが人間かAIかは関係ない。テストが品質の最後の砦になる。

E2Eテストの敷居も下がった。AIに頼めばDockerで環境を立てて、Playwrightでブラウザを動かして、テストまで書いてくれる。以前なら環境構築だけで半日かかっていた作業が、数分で終わる。テストを書かない言い訳がなくなりつつある。

冒頭のテストを書かないエンジニアは、いまこうしてブログを書いている。