テスト駆動開発 Yahoo! グループで最近行われたディスカッションにおいて、Carlos Ble氏は調査の結果得られた、テストの分類に関する彼の理解を紹介した。
最終的に頭の中にあるのは次の構図です。
デベロッパテスト（"Developer tests"）：
ユニットテスト（"Unit tests"） － 分離され、アトミックで、無害なもの。これはxUnitによって実行されます。
結合テスト（"Integration tests"）：
システムの状態を変更する可能性がある分離されたテスト。すなわちデータベースに保存したり、ファイルに出力したりするもの。結合テストは機能要件をそのまま表すものではありません。これはxUnitで書くこともできます。検証するのは対象となるコードと、サードパーティーのツールや自分たちが書いたコードの別レイヤとの結合です。別のレイヤというのはつまり、ビジネスロジックレイヤがデータアクセスレイヤを要求するといったものです。
機能テスト（"Functional tests"）：（システムテスト（"System tests"）とも呼ばれる）
システムを全体と見た時の一部分、つまり機能要求を実行するテスト。このテストはシステムの状態を変更するかもしれません。
プロダクトオーナテスト（"Product Owner test"）：
受入テスト（"Acceptance tests"） － 技術側の人間ではないプロダクトオーナによって入出力が検証される機能テスト。
John Donaldson氏はこれに対して、テストの役割とテストの型に注目した多次元モデルを紹介した。
あなたが提示したテストの捉え方は良いと思います。しかしこれはもっと大きなモデルの一例なのではないでしょうか。そこには（少なくとも）アクタの役割とテストの型が含まれています。
アクタの役割 － 開発者、テスタ、品質保証（"QA"）、ユーザ、スポンサ、など。
テストの型 － ユニット、結合、機能、システム、受入、耐久、スモーク、など
これまではどんな状況でも、どのロールがどれを行うかが決まっていたのかもしれませんが、次のプロジェクトでは違うかもしれません。
Dale Emery氏はどういう種類のテストを書いているのか分からないということは、コードの不吉な匂いであり、明確さが欠けていることを示しているとし、同時に、あるテストはいくつかのカテゴリーに分類できるのであり、重要なのは現在の視点であると提言した。
私が思うに、課題となっているのは、どの側面に注目するかによって、どんなテストもいくつかのやり方で分類できてしまうということです。そしてテストを分類するための側面は数多くあるのです。そのうちいくつかについてはここで論じています。http://cwd.dhemery.com/2004/04/dimensions/
したがって私は「どういう種類の」テストであるかということにはあまり興味がありません。関心があるのはむしろ、どんな時でも自分の目的に応じた最も重要な側面のうちで、問題となっているテストがどこに該当するのかを知ることです。最もよく考えるのは次のようなことです。
- このテストがどの「ユニット」を定義してテストしているのか。（どのシステム、サブシステム、オブジェクト、あるいはその連携なのか） － また、どの機能を定義してテストしているのか。
- このテストの主要顧客は誰か。このテストの実行結果を最も気にするのは誰なのか。
- このテストの実行結果に基づいて、どのような決定がなされるのか。
Charlie Poole氏はBle氏の分類を詳細に分析した上で次のように論じている。
私の考えでは最も重要な区別は、開発者の意図によるテストと顧客の意図によるテストとの間に存在します。
この議論が浮き彫りにしているのは、テストの分類がきわめて紛らわしいものだという事実だ。新人にとっては特にそうである。多数派の意見によれば、テストの分類に関する正しいアプローチは多面的なものであり、適切な分類法はユーザの現在の意図とコンテキストに左右されるのである。