テストは安心して変更し続けるためにある。小さいテストを中心に、守りたいものは挙動で押さえる。
目次
テストは変化できる能力のためにある
自動テストがあれば、信頼性を落とさずにコードを変え続けられる
- デバッグが減り、リファクタリングに踏み切れる
- 実行できる文書になり、レビューも軽くなる
- 信頼できないスイートは無いより悪い。落ちたらすぐ直す
規模で分け、小さいテストを中心にする
範囲がどうであれ、できるだけ小さい規模で書く
| 規模 | 許されること | 主な用途 |
|---|---|---|
| 小 | 1プロセス内だけ | 依存をダブルにしたテスト |
| 中 | 1台のマシン内（DB も可） | UI とサーバーの組み合わせ |
| 大 | 制約なし | システム全体の検証 |
- 規模は行数でなく使える資源で決め、違反は道具で落とす（§11.2）
範囲は規模とは別の軸
範囲は検証するコードの量で、実行されるコードの量ではない
- 広い範囲でも、依存をダブルにすれば小テスト
- 1メソッドでも、ブラウザが要れば中テスト
- 部品間の契約は狭いテストで確かめられない。範囲を混ぜる
壊れてほしくないものは挙動でテストする
壊れてほしくないものは、性能やアクセシビリティも含めすべてテストする
- 無関係な変更で壊れたら、テストを足すのは自分の側
- カバレッジは目標にした途端に意味を失う。穴探しの手がかりにとどめる
- 質は「期待される挙動を守れているか」「安定しているか」で測る
大きなスイートが腐る道筋
大きなスイートは、脆さと遅さで腐る
- 脆さ：モックの使いすぎで無関係な変更に落ちる（テストダブル）
- 遅さ：決め打ちの
sleep()をやめ、タイムアウト付きでポーリングする
人に残すもの
検索結果の質や込み入った脆弱性の発見は、人の判断が勝る
- 人が見つけた欠陥は、自動テストに落として見張らせる
関連
- コードレビュー — テストを含む変更はレビューが軽くなる
- バージョン管理 — 開発ブランチの代わりに、テストと CI で安定させる
- ソフトウェアエンジニアリングとは何か — 早く見つけるほど安い