- 一つのテストに一つのアサーション (論理的なアサーション)。
- 一つのテストで確認する意図は一つにすること。
- アサーションの機能が弱いために、一つのことを確認するためにいくつかの実装上のアサーション (物理的なアサーション) を書かざるをえないケースはありえる。
- よいユニットテストは一瞬で実行を終えなければならない (そうじゃないとコードの変更のたびに実行するのが面倒になる)。
- 書くべきテストとは、同値分割と境界値分析を考慮して、モジュールの外面的な振舞いを検証するテストで、エラーを見つけられそうなもの。
- 「テストとは、エラーを見つけようとしながら、プログラムを実行する過程である。」
- 「良いテスト・ケースとは、まだ発見されていないエラーを検出する確率の高いものである。」
- ホワイトボックスでの同値分割と境界値分析によって導かれるすべてのケースを網羅すること、ではないのがポイント。それによって外面的な振舞いに影響を与えるものが基本的な検証すべきケース。
- テストコードで条件分岐をしないこと (二つのテストにわける)。
- バグを直す前には必ずバグを再現させるテストを追加してから直すこと。
- 将来のモジュール変更でのデグレを防ぎ、また類似のモジュールをつくるときにエンバグを抑止できます。
- Test Double はなるべく使わずにテストすること。どうしても必要なときに仕方なく使うこと。
- 基本は使わないでテストすることです。スタブも、実モジュールが呼び出せ、使うことに支障がないなら実モジュールを使いましょう。
- では、実モジュールを使うことに支障がある場合とは。セットアップが大変手間 (Test Stub、Dummy Object)、レスポンスが大変悪い (Fake Object)、検証が困難 (Mock Object、Test Spy) などの場合です。
- その中でも Test Stub と Dummy Object は比較的問題が少ない。それ以外を使いたい誘惑にかられたら、とくにその目的を見直すこと。
- テストの後始末 (リソースの解放、削除など) を必ず行うこと。
- 意図した入力をしたい、任意の入力をしたいという目的では Test Stub を使いましょう。
- ただ動作させるためのスタブが必要で、なにもしなくていいときは Dummy Object を使いましょう。これは API が合っているだけのスタブです。
- 内部的な出力を 検証したい ときには Mock Object を使いましょう。検証の意図がない場合は、基本的にライブラリそのものをコールします。
- 外部リソース (ファイル、DB、API、etc) をコールするテストが重たく、チューニングが必要であり、実際に外部を呼び出しての検証は別の場所で担保できるときは、Fake Object を使いましょう。
- Test Spy が必要なとき、自分でテスト意図がわかってるでしょうから、説明は不要です。必要なときは使ってください。
- これらに当てはまらないときは、Test Double を使うべき場面ではありません。Test Double のことは忘れてテストを動くようにしましょう。
- 基本的な考え方としては、入力値を Dummy Object や Test Stub で代用することはよくあります。Mock Object や Fake Object のような出力に対する Test Double を使いたくなったら、それは本当にそこでテストすべきか考えるほうがいいです。
- Test Double の用語は xUnit Patterns の整理に従いました。Wiki に載ってるとおり、書籍での用法にはばらつきがあるので、Wiki を一度は眺めておくといいと思います。
- Test Double の説明 (xUnit Patterns)