ユニットテストには保守しやすさが要る。無関係な変更で落ちる脆さと、落ちても原因が分からない不明確さを避ける（規模と範囲はテスト）。
目次
要件が変わらない限りテストを直さない
一度書いたら、挙動が変わるまで触らずに済むテストを目指す
| 変更 | 既存のテスト |
|---|---|
| リファクタリング | 変えない |
| 新機能・バグ修正 | 足すだけ |
| 挙動の変更 | 直す |
- 公開 API 経由で呼ぶ。「公開」はチームの外に出している境界
- やり取りではなく状態を確かめる。気にすべきは結果だけ
- 速く決定的ならモックより本物（テストダブル）
落ちたテストを読めば分かるようにする
テスト本体と失敗メッセージだけで、何が悪いか分かるようにする
- メソッドごとではなく挙動ごとに書き、名前に操作と期待を入れる
- 大事な値をヘルパーに隠さず、計算・分岐・ループを入れない
- 失敗時に期待値・実際の値・関係する要因を出す
共有は DRY より DAMP
テストにはテストがないので、重複を減らすより読んで分かることを優先する
- テストデータは、関心のある値だけ指定し残りは既定値で埋める
- 一律の
validateで検証せず、各テストの意図を見せる - 共有するテスト基盤には、それ自身のテストを付ける
関連
- テスト — 規模と範囲、なぜテストを書くか
- テストダブル — 本物を優先する理由と、モックの使いどころ
- スタイルガイドとルール — 書き手より読み手に最適化する