Jimmy Bogard氏は「価値あるユニットテストのために」という記事を書いており、そこで３つのルールを提示している。
- 「テストの名前はユーザの視点から見たwhatとwhyを記述しなければならない」 – この考え方は、開発者がテストの名前を読んで、意図されたふるまいがどのようなものであるかを理解できなければならないということだ。
- 「テストもコードであることには変わりないのだから、多少は愛情を注げ」 – プロダクションコードに対してしかリファクタリングを行ってはいけないわけではない。可読性の高いテストは保守も容易であり、次の人にとっても理解しやすい。「長くて複雑なテストは本当に嫌いです。初期化に30行を費やしているようなら、どうか生成メソッドの後ろに隠蔽してください。長いテストに開発者はイライラして、ディスプレイにへばりつついたままになります。プロダクションコードに長いメソッドを書かないようにしているのに、テストコードでなら許されるなどということがあるでしょうか。」
- 「１フィクスチャを求めるパターンや組織のスタイルに決め打ちするな」 – 標準的な１クラスに対して１テストフィクスチャというパターンは、時としてうまく行かないこともある。
Lior Friedman氏はこれに次のルールを加えている。「ルール０ – 内部構造ではなく外的なふるまいをテストせよ」。つまり、クラスに対する期待値をテストするのであって現在の状態をテストするのではないということだ。
Ravichandran Jv氏はこれに自身のルールを付け加えている。
- １テストに１アサーション（可能であれば）
- テストの内部に「if else」句があれば、分岐を個別のテストメソッドに移動せよ。
- テスト対象のメソッドに関して、そこにもif else分岐があったら、そのメソッドはリファクタリングするべきだ。
- メソッド名はテストの種類であるべきだ。たとえば、TestMakeReservationはTestMakeNoReservation()とは違う。
NUnitの作者であるCharlie Poole氏は「１テストに１アサーション」を「論理的なアサーション」と言い換え、次のように説明する。「時にテストAPIが表現力に欠けているせいで、望む結果を得るために複数の物理的なアサーションを書かなければいけないことがあります。NUnitフレームワークAPIの開発の大部分は、１つのアサーションがより多くを行えるようにする試みから生じたものでした。」
Bryan Cook氏は独自に注目すべき一覧を作っている。
- 必須：フィクスチャは一貫性を持って命名せよ
- 必須：テスト対象コードのネームスペースを模倣せよ
- 必須：Setup/TearDownメソッドは一貫性を持って命名せよ
- 要考慮：テストとプロダクションコードを分離せよ
- 必須：テストは機能に従って命名せよ
- 要考慮：期待される例外には"Cannot"という接頭語を用いよ
Cook氏は他にもたくさんのヒントを提示している。
最後に、２人がGerard Meszaros氏の書籍「xUnit Test Patterns: Refactoring Test Code」を勧めている。
なお、これまでInfoQで紹介した記事には次のものがある。Recommended TDD Tutorials、Designing for Testability、Unit Testing Tips from Google、TDDを根づかせる:導入の問題と解決策。