AI がコードを書く時代に、テストの意味は変わったか
書く速度が上がると、律速は「書く」から「確かめる」へ移ります。テストの目的自体は変わりませんが、置き場所と重心は変わりました。連載の前提を整理します。
単体テストの粒度 ── AI に書かせると何が起きるか
指示なしに書かせると、網羅率は上がるのに壊れやすいテストが積み上がります。原因は粒度の選択にあります。何を単位とみなすかを決める判断軸を整理します。
テストを速くする ── 実行時間が開発速度を決める
遅いテストは、やがて書かれなくなり、実行されなくなります。速さは快適さの問題ではなく、テストが使われ続けるかどうかの条件です。計測から並列化まで順に扱います。
E2E テストをどこまでやるか ── 壊れやすさと価値の交換
E2E は「本当に動くか」に最も近い一方、遅く・不安定で・原因が読めません。書けるようになったからこそ、増やす前に線を引く必要があります。判断軸をまとめます。
リグレッションテストの設計 ── 何を固定し、何を固定しないか
壊していないことを確認するテストは、固定する対象の選び方がすべてです。固定しすぎると変更のたびに赤くなり、緩すぎると壊れても気づけません。線の引き方をまとめます。
スナップショットテストの功罪 ── 通っているのに何も守っていない状態
出力を丸ごと記録して比較する手法は、書くのが最も楽で、形骸化するのも最も速い。差分をそのまま承認する運用に陥る構造を分解し、それでも使う場合の条件を整理します。
LLM 出力のテスト ── 毎回変わるものをどう検証するか
完全一致が使えない対象に、従来のテストをそのまま当てても機能しません。非決定的な範囲を狭く閉じ込め、残った部分を層に分けて検証する方法を整理します。
評価セットの作り方 ── 30件から始める
大規模な評価基盤を作る前に、まず数十件の評価セットを作るほうが効きます。何を集め、どう分類し、どこで増やすか。失敗例を優先して集める理由まで含めて扱います。
GitHub Actions でのテスト自動化 ── 構成の基本形
ワークフローは、置き場所を間違えると待ち時間と費用の両方が膨らみます。ジョブの分け方、キャッシュ、並列度、失敗時の証跡まで、実際に使える構成の型をまとめます。
CI のコストを下げる ── 無駄な実行を止めることから
CI の費用は実行時間に比例します。速くする前に、そもそも流さないという選択肢があります。打ち切り・絞り込み・分割・実行環境の選定を、効果の大きい順に整理します。
フレーキーテストと向き合う ── 放置が最も高くつく
同じコードで成功したり失敗したりするテストは、再実行で流されがちです。しかし放置すると、赤が信用されなくなり、テスト全体が機能しなくなります。検知・隔離・修正の運用をまとめます。
テスト戦略のアンチパターン ── ここまでを裏側からまとめる
網羅率至上主義、E2E偏重、直さないフレーキー。よく見る失敗を10個に整理し、それぞれ何を誤解しているのかと、どう戻すかをまとめます。連載の区切りとしての総括です。
まずは、現状を聞かせてください。
要件が固まっていなくて大丈夫です。現状診断と方針提案までを無料でお手伝いします。