ユニットテストの基礎

1章、2章は割愛

様々なアサーション

assrtThat + Hamcrestのアサーションを使えば失敗時にわかりやすいメッセージが表示される。
assertTrueではスタックトレースのみ。
ただし、前者を利用しても提示できる情報には限界がある。シンプルなテストであればassertTrueの方が良いという派閥もある。

メソッド名	内容
eqaualTo	コレクションやオブジェクトの比較。is単体でもほぼ同じことができる
not	否定
nullvalue	nullであること。多くの場合、非nullチェックは冗長であり、あまり価値はない
notNullValue	非nullチェック
その他は以下を参考に。
[Java Hamcrest] (http://hamcrest.org/JavaHamcrest/)
HamcrestのMatchersに定義されているメソッドの使い方メモ

AAAとは?

テストが実行される際にシステムが適切な状態にあること

テストコードの実行

テスト対象の振る舞いが正しいかどうかの確認

After(事後処理)が含まれる場合もある

テストコードはテスト対象に依存してはならない。
ただし、テスト対象の設計を変えればテストをしやすくなる場合、積極的に採用すべき。 -> テストしやすいコードは実運用にも適している場合が多い

テストケースごとに１つずつテストメソッドを用意し、検証対象の振る舞いを的確に表す名前をつける

ユニットテストは永続的で信頼できる情報を提供すべき。
普段コメントで書いていることはほぼユニットテストに置き換え可能

正確な名前をつけることによって、テストの内容を詳細に理解できるようにすべき。

//何らかの処理を行うと何らかの結果が発生する
doingSomeOperationGenerateSomeResult

// 何らかの条件下では何らかの結果が発生する
someResultOccursUnderSomeCondition

テストがわかりにくいと感じた場合、コメントを追加するのではなく、名前を改善することから着手する。

全てのテストが常に成功しているべき。

問題があることに気づくのが遅れるほど、解消のためのコストは増大するため、テストの実行対象を減らすのは得策ではない。
データベース等の低速なリソースを使っていなければテストはすぐに完了するので、常に全てのテストを実行すべき。
以下のような方法で高速化を図る。

Categories · junit-team/junit Wiki
Infinitest

最善の対策は、実行に時間のかかるテストを慎重に減らしていくこと。