自分に必要なとこだけメモする。
ユニットテストの基礎
1章、2章は割愛
様々なアサーション
Junitでのアサーション
assertThat(何かと何かが等しいことを示す)
assrtThat + Hamcrestのアサーションを使えば失敗時にわかりやすいメッセージが表示される。
assertTrueではスタックトレースのみ。
ただし、前者を利用しても提示できる情報には限界がある。シンプルなテストであればassertTrueの方が良いという派閥もある。
重要なHamcrestマッチャー
| メソッド名 | 内容 |
|---|---|
| eqaualTo | コレクションやオブジェクトの比較。is単体でもほぼ同じことができる |
| not | 否定 |
| nullvalue | nullであること。多くの場合、非nullチェックは冗長であり、あまり価値はない |
| notNullValue | 非nullチェック |
| その他は以下を参考に。 | |
| [Java Hamcrest] (http://hamcrest.org/JavaHamcrest/) | |
| HamcrestのMatchersに定義されているメソッドの使い方メモ |
テストの編成
AAAに基づいた一貫性の実現
AAAとは?
Arrange(セットアップ)
テストが実行される際にシステムが適切な状態にあること
Act(操作)
テストコードの実行
Assert(アサーション)
テスト対象の振る舞いが正しいかどうかの確認
After(事後処理)が含まれる場合もある
個々のメソッドについてテストするのではなく、対象のクラスの持つ振る舞いをテストする
- ATMの例 -> 出金のテストを行うには入金をしてからでないとできない。
- 全体的な観点を持つべき
テストと対象のコードの関係
テストコードはテスト対象に依存してはならない。
ただし、テスト対象の設計を変えればテストをしやすくなる場合、積極的に採用すべき。 -> テストしやすいコードは実運用にも適している場合が多い
一つの目的に特化したテストの価値
テストケースごとに１つずつテストメソッドを用意し、検証対象の振る舞いを的確に表す名前をつける
- テストが失敗するとテストの名前が報告されるため、どの振る舞いに問題があったのかすぐにわかる
- 失敗したテストの分析にかかる手間を最小限にできる
- すべてのテストケースが実行されることを保証できる
ドキュメントとしてのテスト
ユニットテストは永続的で信頼できる情報を提供すべき。
普段コメントで書いていることはほぼユニットテストに置き換え可能
一貫性のある名前
正確な名前をつけることによって、テストの内容を詳細に理解できるようにすべき。
- テストの名前は7語程度にすべき
//何らかの処理を行うと何らかの結果が発生する
doingSomeOperationGenerateSomeResult
// 何らかの条件下では何らかの結果が発生する
someResultOccursUnderSomeCondition
意味のあるテスト
テストがわかりにくいと感じた場合、コメントを追加するのではなく、名前を改善することから着手する。
- ローカル変数の名前を改善する
- 意味のある定数を導入する
- hamcrestアサーションを利用する(Junit組み込み以外のものも使ったりする)
- 長いテストは、より短く焦点を絞った複数のテストに分割する
- あまり重要でないコードはヘルパーメソッドや@Beforeメソッドに移動する
@Beforeと@Afterに関する補足(初期化と後処理)
テストと緑バーの重要性
全てのテストが常に成功しているべき。
テストの所要時間を縮める
問題があることに気づくのが遅れるほど、解消のためのコストは増大するため、テストの実行対象を減らすのは得策ではない。
データベース等の低速なリソースを使っていなければテストはすぐに完了するので、常に全てのテストを実行すべき。
以下のような方法で高速化を図る。
- モックオブジェクトの利用
- 実行するパッケージを限定する
- Infinitestを使って常にバックグラウンドで実行する
- 特定のアノテーション(@Category)がついているテストだけを実行する
Categories · junit-team/junit Wiki
Infinitest
最善の対策は、実行に時間のかかるテストを慎重に減らしていくこと。
テストを無視する
- テストが失敗した際には１つずつ解決する
- @Ignoreアノテーションが付いているメソッドは実行されない