テストが通っても本番で落ちる｜緑を信じて1日分飛ばした

プログラムには「ちゃんと動くか自動で確かめる仕組み」があります。テストと呼ぶやつで、全部OKやと画面に緑のランプがずらっと並ぶ。この緑が出たら安心してええ、と思ってました。

自作のツールに機能をひとつ足した日。テストは全部通りました。緑。ああ今日はきれいに終わったな、と。そのあと本番を1回動かしたら、いきなり落ちました。

テストが通っても本番で落ちる。しかもこれ、AIに実装を任せとると出やすい形でした。中身のコードと、それを確かめるテストが、同じ相手から一緒に出てくるからです。この記事は、その日に踏んだ罠と、二度と踏まんように足した仕掛けの話。

テストは全部緑、なのに本番の1回目で落ちた

足した機能自体はしょうもないもんです。処理した結果に「どの設定で動かしたか」の印を2つ残すだけ。あとから振り返る時に、条件がバラバラのデータが混ざってへんかを確かめるための印です。

その印を、命令を出す側から受け取る側へ渡す配線を4か所に入れました。テストも11本書いて、全部緑。ここまでは順調でした。

本番の処理を走らせたら、そこで止まりました。エラーは英語で1行。意味は「そんな名前のものは受け取れません」。渡した先に、受け取る口が無かったんです。

しかもこれ、その日ぶんの記録を作る処理でした。あとから作り直せる種類のデータやない。落ちた日は、まるごと欠番になりました。

配線したのは4か所。実は5か所目がありました。

5か所目は本番だけが通る中継地点です。テストのほうは、その中継を通らん別ルートで走っとった。だから配線が1本抜けとっても、テストからは何も見えへんかったわけです。

「テストが緑＝動く」やと思い込んでました。ほんまは「テストが通った道は動く」でしかない。通ってへん道のことは、緑は何も言うてくれません。

11本のテストは、どれも部品ひとつずつの正しさを見とりました。設定を読み込む部品は正しいか、計算する部品は正しいか。そこは全部合っとった。

足りんかったのは、部品と部品の「つなぎ目」を見る目です。ここを増やさずに本数だけ12本、13本と足しても、同じ場所を何回も確かめるだけやったと思います。

足したのは、プログラムを動かさずにソースコードを文章として読むテストです。やってることは3つだけ。

この形のええところは、データも環境も要らんことです。ファイルさえあれば一瞬で終わる。だから本番と同じ材料が手元に無い日でも、つなぎ目だけは毎回確かめられます。

このテスト自体も、いつも使ってるClaude Codeと一緒に書きました。同じもんを自分の環境で作るなら、頼み方はこれで足ります。文中の「引数」は、ここまで「渡しとる名前」と呼んできたもんと同じです。AIに投げる時はこっちの言い方のほうが通じます。

Aというファイルの中で、Bという関数を呼び出しているところを探して、渡している引数の名前を全部集めてください。次にB自身が受け取れる引数の名前を集めて、前者にあって後者に無いものがあれば失敗するテストを書いてください。プログラムは実行せず、ソースを読むだけで判定してください。

AとBのところに、自分のファイル名と関数名を入れるだけ。一度書いたらずっと効き続けるので、手間の割に見返りがデカかったところです。

ここが今回いちばん学びやったところです。検査を足しただけやと、検査のほうが黙って壊れます。

いちばん効いてるのは1つ目やと思います。見つからんかったことを「異常なし」にせん。空振りと無事は違う、というだけの話やけど、自分はこれで1日ぶんのデータを飛ばしました。

AIに実装を任せると、コードもテストも一緒に出てきます。速いし、たいてい合っとる。ただ、テストが見に行く道と本番が通る道がズレとる時、その一致は誰も確かめてくれません。

緑の本数を増やしても、通っとる道が同じなら見とる場所は変わらん。次に何か足す時は「これ、本番と同じ道を通っとる？」だけ先に聞くようにしました。