#なぜ今日これを選んだか

AIにコードもテストも書かせるようになって、「テストが通った＝正しい」と思い込みやすくなった。けれど、モックで固めたユニットテストは、本番の設定漏れや結合の食い違いを原理的に見つけられない。どのテストが何を捕まえるのかを整理し直す記事で、品質を上げたい今の自分に一番刺さった。

#要点

• テストの役割は「検出できる不具合の種類」で決まる。ユニットは細かなロジック、統合はDBや外部サービスとの接続、E2Eは画面と全体の流れ、探索的テストは誰も想定していなかった使い方を受け持つ
• 速さも役割の一部。型検査・lint・ユニットテストはAIの試行ループの中で毎回回せるが、E2Eや統合テストは遅いので回し方の戦略が要る
• 一番効くのは「誤ったコードをそもそも書けなくする」設計。金額と税率を同じ number にせず別の型にすれば、取り違えはコンパイル時に弾ける。この型とルールの設計は人が担う投資で、AIはその枠の中でテストを書いて実行する

#自分にとっての示唆

AIに書かせたテストが緑でも、それは「そのテストが見ている範囲」が正しいだけだ。外部APIをモックしたテストは、環境変数が本番に無いことを絶対に見つけられない。自分がこれから作る可動域アプリも同じで、角度計算の純粋関数はユニットテストで固められるが、カメラ・姿勢推定・端末の向きが絡む部分は実機で確かめるしかない。明日からは、新しい機能を足すたびに「この不具合はどの層のテストで捕まるか」を一行メモに書く。どの層にも当てはまらない不具合があれば、そこが今の穴だ。まずは角度の値を「度」と「ラジアン」で別の型に分け、取り違えを型で潰すところから始める。

原文を読む →