JUnit 実践入門 体系的に学ぶユニットテストの技法 - 第2章 ユニットテスト 何のためにテストするのか
第2章 ユニットテスト 何のためにテストするのか
2.1 ソフトウェアテストとは
- 検証する内容を定義し、ソフトウェアが期待通りに動作するのかを確認すること
- テストを作るのは、テスを行うテスター自身であり、ソフトウェアの仕様や要件を基に、テスト項目を抽出する
- 検証項目が明確でなく、人間の感覚に依存するテストもある
ソフトウェアテストの特徴
- 設計段階で徹底的に検証して品質を高める手法は、効果的でない
- プログラム上の問題や制約などが実際に作ってみなければわからないことが多い
- 一度作ったプログラムを破棄して作りなおすことが比較的容易
- 作りながら同時にテストを行ったり、実施したテストから得られたフィードバックからテストを追加したりする方法が有効
テストケースとテストスイート
- テストケース: 1つのテスト項目のこと
- テストの前提条件、 実行する操作、期待される値、状態などを含む
- 『どのような条件でどのような操作をしたら、どういう結果が期待されるか』
- テストスイート: いくつかのテストケースをまとめたもの
ソフトウェアテストの目的
- 品質向上だけじゃない
- 機能テストは、進捗確認にも使える
- 『設計された全機能のうち、どこまでテストグリーンになるか』
- ユニットテストは、設計妥当性の確認にも使える
ソフトウェアテストの限界
- 全パターンをテストすることは不可能
- 『完璧にテストは不可能である』
- テスト方針合意の重要性が生じる
2.2 テスト技法
ホワイトボックステストとブラックボックステスト
- ホワイトボックステスト: 内部ロジックや仕様に基づいてテストケースを設計。すべてのロジックを実行する。したがってプログラマがテストを実施。
- ブラックボックステスト: 外部仕様のみからテストケースを設計。業務知識が重要。
- 本書は、ホワイトボックス寄りな内容
同値クラスに対するテスト
- 代表値に対するテストで全パターンテストすることを代替する
境界値に対するテスト
- 不具合が混入する可能性の高い、プログラムの挙動をわける境界値近辺の2値でテストを実施する
2.3 ユニットテスト
- クラスやメソッドを対象とする、最も小さい粒度のテスト
- 対象が仕様どおりかを確認する
ユニットテストの特徴
ユニットテストの目的
- 直接の目的は、品質向上ではない
- 目的は、仕様を明確にし、仕様を保証すること
- テストコードを先に記述する、テスト駆動開発などもある
ユニットテストのフレームワーク
2.4 ユニットテストのパターン
xUnit Test Patterns から重要なパターンを引用
- 自動化されたテスト - 繰り返しいつでも実行できる
- 不安定なテスト - 結果が一定でないテストを避ける
- テスト失敗の状態を放置しない
- ドキュメントとしてのテスト - 仕様書として読める
- テストケースの可読性が高いと、プロダクションコードのコントが減る。
- 問題の局在化 - テスト失敗時に問題特定しやすい
- テストケースは「小さく」「たくさん」
- 不明瞭なテスト - 可読性の低いテストコードは避ける
- リファクタリング大事
- データクラスの検証は、フィールドごとにするか、カスタムmatcherが吉
- 独立したテスト - 実行順序に依存しないこと
- シングルトンなリソースとかでは起こりがち
- テスト後に、テスト前状態に戻すのがミソ
- 全テストボリュームが大きくなってきた時に、分散実行できるように！
- ハードコーディングされた設定ファイル読み込み、ミュータブルオブジェクトをシングルトンにする、などで発現しがちなので、注意
シングルトンオブジェクトの注意点
- テストの独立性を破壊する
- テストの後処理と初期化処理を複雑にする
- テストを不安定にする
- テストを並列実行できない
- モック/スタブとの関係
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
- 作者: 渡辺修司
- 出版社/メーカー: 技術評論社
- 発売日: 2012/11/21
- メディア: 単行本（ソフトカバー）
- 購入: 14人 クリック: 273回
- この商品を含むブログ (65件) を見る
