なぜ自動テストをするのか
バグは補足されるのが開発サイクルの後ろになるほど修正のコストが高くつく。開発サイクルの早い段階で高速に自動化テストを回し、バグを捕捉したい。
また、「バグをほそくすること」はテストの同期の一部に過ぎない。ソフトウェアテストを望む理由として「変化を可能とする能力」を備えておくためというものがある。
- 新機能追加
- リファクタリングの実施
- 大規模な再設計への着手
以上のどれを行っていても、自動テストは間違いを素早く検知してくれる。
より高速に反復できる企業こそが、変化する技術、市場の状況、顧客の好みなどにより迅速に対応できる。
良いテスト文化
テストを書くことは、自動テストの最初のステップに過ぎない。
テストを書いたらその後、実行し、その結果に適切に反応しなければならない。それも頻繁に。
そして最も大切なのは、テストの失敗にどう対処するかである。テストの失敗が積みあがるに任せず、数分以内に何かしらの対処されるのが理想的だ。テストの信頼性を損なってはならない。
以上より、良いテスト文化が浸透している組織では以下の行動が実践される。
- テストを書く作業の分担共有をみんなに促す。
- 定期的なテスト実行を実施、また、その仕組みを担保する。
- テストのプロセスに存在する高い信頼性を維持するために、破綻したテストの迅速な修正を行う。
自動でコードをテストする利点
以下の通り、
- デバッグの減少
- 変更への信頼性の増大
- ドキュメンテーションの改善：良いテストコードはそれ自体ドキュメントとしても機能する。ちゃんと更新される。
- レビューの単純化：自動テストをパスしていることを見ればよくなる。
- 思慮に富む設計：モジュール化し、蜜結合を避けるようになる。
- 高速で高品質なリリース：テストが自動で回るのでリリースサイクルが早くなる。
テスト規模
グーグルではテスト規模を大・中・小に分類している。
- 大：他ホストをCallする。システム全体のE2Eテストを実施する。など。
- 中：単一マシン内で実施される。複数プロセスにまたがったテスト。SleepやI/Oの確認も可能。(単一マシン内で)別ネットワーク(ブロック)のモジュールがCallされることも。
- プロシージャコールなどに伴う、リモートマシンへのアクセスは禁止。
- 小：単一プロセス(シングルスレッド)で実行できる処理の確認。Sleep、I\O、処理のブロックを伴う関数呼び出しなどは不可。
- これらの制約の目的は、小テストに、テストの遅さや非決定性の主要な要因となっているものへのアクセスが存在しないようにするため。
全テストに共通な属性
すべてのテストは密閉された状態を目指すべき。
→ テストは環境作成・実行・解体に必要なすべての像法を含むべき。
→ 例えば共有データベースなどの外部リソースへの依存は厳禁。テストは当該挙動を確認するのに必要最小限の情報のみ保持すべき。
分岐やループなどを含むテストコードを書くのは非推奨。
→ 実装されたあらゆる分岐やループはテストされるべきだが、テストコードのテストはできないため。。。
テスト範囲
テスト範囲：あるテストでどれだけの量のコードが検証されたか。
（検証される側の）コードが、、
- 狭い：ユニットテスト（個別のクラスやメソッド）。特定ロジックのテスト。
- 中範囲：インテグレーションテスト。少数のコンポーネント間。（例）サーバーとDBの相互作用。
- 大範囲：ファンクショナルテスト。E2Eテスト。システムテスト。
テスト範囲の構成に関して理想的には、、
- テスト全体の80％が狭い範囲のテストであるべき。
- 15%が中範囲。5％が大範囲。
イメージ（雑）
Beyonceルール
破綻してほしくない部分すべてに自動テスト実施しよう。
「そんなにすきならそいつにテストつけとけばよかったのに。」（？？？）
