テスト自動化について5分で分かるまとめ

みなさんこんにちは。@ryuzeeです。

テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。

テスト自動化/テスト駆動開発について

XPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つである
このプラクティスのみで１冊の本が書けるくらい奥が深い
基本的な方法
- 失敗するテストを書く
- できる限り早く、テストがパスするような最小限のコード本体を書く
- リファクタリングをする
適用範囲
- 通常では、独立性の高いクラスやファンクションへの適用が良い
- GUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい
- 既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい
問題点
- 開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保証できない。あくまで開発者が作成するコードが、開発者が認識するテストコードに適合していることのみが保証される

自動化されたテストが満たすべき性質

テストは以下の条件を満たしている必要がある。

簡単実行
- テストの準備に大量の時間や人手がかかるようにしない
自己検証
- テストが成功したか、失敗したかはプログラムが判断する。（人手で判断しない）
繰り返し可能
- 何回でも繰り返し実行できること。また実行ごとに結果が変わらないこと
独立性
- 環境や外部のコンポーネントに依存しないこと
- テストケースの実行順序に依存しないこと

自動テストをどこまで作るべきか？

テストの自動化にはコストがかかるため、自動テストによるカバレージを100%にすることを目標としてはいけない
バグが無いソフトウェアは本当に良いソフトウェアなの？
- 顧客のビジネス価値の実現に寄与できるのが良いソフトウェア
XPでは、「問題の発生しそうなところはすべてテストせよ」と言っているが、全てをテストせよ、とは言っていない
カバレージ100%への最後の数%はいばらの道。残り数%のテストに、いままで作ったテストと同じだけの労力を必要とすることになる
常に品質最優先ではなく、コスト・スケジュールと照らし合わせた割り切りも必要

テスト自動化のレガシープロジェクトへの導入

レガシープロジェクトとは？
- 自動化されたテストが備わっていないプロジェクトのこと
- 利用している言語やフレームワークには関係ない
レガシープロジェクトの問題点
- 機能追加や改修の際に、現行機能に問題がないことを保証するためには、人力による再テストを実施するしかない
- したがって機能追加・改修が度重なるたびに、テストのスコープが膨れ上がり、開発コストの増大につながる
- 通常、ユニットテストによるテストを意識したモジュール間の依存性が低い状態になっていないため、テストしにくく、結合度の高さ故、変更を加えにくく、予期しない箇所に影響が出やすい
どうやって導入するか？
- 結合テストレベルのテストを先に用意し、想定されるアプリケーション全体の動作をチェックできるようにする
- これによって内部的なロジックを変更した場合でも、アプリケーション機能が壊れていないことは担保できる。その状態で、現行モジュールの修正に際しては、可能な範囲で、ユニットテストが可能になるように作り替えていく。（詳細はレガシーコード改善ガイドを参照のこと）
- テストモジュールについてはSelenium等を利用すると良い
- 新規開発のテストにおいて、SeleniumでHTTPリクエストをトレースする形でテストを作成するのは難しい(UIの変更が頻繁に起こる可能性がありテストのメンテナンスコストが高い)が、一方でUIが既に存在するアプリケーションのSeleniumでのテストは書きやすい