ユニットテストでは見えない本物の振る舞いを確かめる。小さく分け、オーナーを決めて遅さと不安定さを潰す。
目次
ユニットテストだけでは確信が持てない
手で作ったデータは作者の想像の範囲しか試せず、本物との忠実性に穴が残る
| 穴 | 中身 |
|---|---|
| 忠実でないテストダブル | 本物が変わっても気づけない |
| 設定の問題 | 設定ファイルの誤りや互換性 |
| 負荷で起きる問題 | 大量のトラフィックが要る |
| 想定外の挙動・入力 | 書く人の想像力に縛られる |
| 創発的な挙動 | テスト範囲の外の変化に気づけない |
- 大テストが少ないのは、オーナーが曖昧になり朽ちやすいから
小さく分け、対象・データ・検証で組み立てる
巨大な1本より小さめの数本に分け、前の出力を次の入力に連鎖させる
- 対象：密閉した環境が基本。本番だとデータが利用者に見える
- データ：本番から最小限をコピー。直接書くと検査を素通りする
- 検証：アサーションか、新旧を同じ入力で比べる A/B 差分
目的に合わせて種類を選ぶ
確かめたいことと注意点で種類を選ぶ
| 種類 | 要点 |
|---|---|
| A/B 差分 | 想定外の副作用を安く拾う。判断は人 |
| 受け入れテスト | 仕様の誤解を公開 API 越しに確かめる |
| プローバー・カナリア | 本番には読み取り専用の操作だけ流す |
| 性能テスト | 本番に近い条件で比べる |
| 障害注入 | リスクを許容できるシステムでだけ |
開発の流れに乗せる
通常の基盤に載らない大テストは継続的ビルドで回し、遅さと不安定さを優先して潰す
- 速くする：分割して並列に。sleep やタイムアウトは短くできるように
- 失敗を読める出力にし、リクエスト ID で呼び出しを追う
- オーナーを置く：変更をレビューし、落ちたときに頼れる人を決める