良いテストとは何か? 良いテストを書いたかどうかどのように分かるのだろうか?
Kent Beck氏(リンク)が、テストとは次のようであるべきだと仮定した。
- 分離していること (他のテストが存在していようといまいと、その結果に影響を受けないこと)
- 自動化されていること
- 速く書けること
- 速く実行できること
- 一意であること (他のテストによって提供されたり、他のテストとの相関関係があったりすることなく、確実なものであること)
Roy Osherove氏(リンク)は、良いテストは３つの基本的なプロパティがあることを付け加えた。それは、維持可能なこと、信頼できること、可読性があることである。
Mike Hill氏(リンク)はもっとずっと長いリストを持っている。
- 短いこと。一般的に１ダース未満のライン数であること。
- .実行中のアプリケーションの内部のオブジェクトではなく、代わりに専用のテストアプリケーションをテストする。
- コードの極めて小さな部分だけを呼び出す。それは、大抵、１つの機能の１つのブランチである。
- グレイボックスとして書かれていること。言い換えれば、まるでブラックボックスであるかのように読み込むが、時々ホワイトボックスの知識を利用する。(大体は組み合わせの問題を避けるための重要な要素である)
- 出荷するコードと同じ基準でコーディングする。言い換えれば、コーディングが優れていることをチームが現時点で最も良く理解していること。
- アプリケーションの他のすべてのマイクロテストと組み合わせて、コミットのゲートウエイの役目をする。つまり、開発者は実行してグリーンになるマイクロテストはすべて、いつでもコミットするように奨励される。そうでなければ(強く、時には意地悪く)コミットしないように言われる。
- テストするオブジェクトを完全にコントロールし、その結果、自己完結する。言い換えれば、テストコードと依存性グラフ以外に依存せずに実行される。
- 非常に短い時間で実行する。
- 通常、テストするはずのコード変更の前に書かれる。
- 間違ったニセモノの技術がいろいろあるが、それら不適当なものをほとんど、またはすべて使うことを避ける。
- ...
Mike氏とRon Jeffries氏は、TDDの主要な価値は、デザインを簡略化し、生産性を改善することだと思い出させてくれる。コード品質の改善とバグの削減は、重要な二次的影響である。
Jeremy Miller氏(リンク)は、良いユニットテストが以下のようなものであると付け加えた。
- 順番に依存せず、独立していること。テストする人がどの順番を選んでもテストを実行できるようにすべきである。
- 意図が明らかであること。もっとも良いユニットテストは、どのようにオブジェクトAPIが使われるように意図されているか、読む人に明らかである。
- 設定が簡単であること。
最後に、Ed Burnette氏(リンク)が書く。どんな局面でもユニットテストが繰り返せるようにすること。境界の状態をテストし、いつも100%テストが通るようにしておくこと。
原文はこちらです：http://www.infoq.com/news/2008/10/qualities_good_test