テストの多様で幻想的な形状について

最近、Twitterなどで、チームがどのようにテスト作業を分割すべきかについて、再び議論が活発化しています。特に、Tim Brayは自動テストを真剣に受け止めるべきだと強く主張しています。私の writings をよく知っている人なら、私が彼に非常に同意していることをご存知でしょう。

彼が彼の投稿で提起した点の一つは、次の2つの画像についてです。

これらの「いびつな塊」はどちらも、テストピラミッドの古い画像に対する反動です。

これらの画像のポイントは、さまざまな種類のテスト、特に単体テストとより広範なテストのバランスに、どれだけの労力を費やすべきかを示すことです。ピラミッドは、ほとんどのテストを単体テストとして行うべきだと主張しており、ハニカムとトロフィーは、単体テストを比較的少なくして、主に統合テストに焦点を当てるべきだと主張しています。

この議論で私が抱えている2番目に大きな問題は、人々が単体テストと統合テストの違いをどのように見ているのかが明確でないために、議論が不透明になっていることです。

「単体テスト」と「統合テスト」という用語は、ほとんどのソフトウェア用語の曖昧な基準から見ても、常にかなり曖昧でした。私が最初に理解したように、それらは主に組織的な問題でした。大規模なウォーターフォール型ソフトウェアプロジェクトの時代に戻ってみましょう。私は数ヶ月間、コードの塊に取り組んでいます。私は一人で、あるいは小さなチームで作業しているかもしれません。いずれにせよ、私はこの塊を、隣接するものとは比較的独立して作業できる概念的な単位と考えています。コーディングが完了したら、単体テストチームに引き渡すことができます。単体テストチームは、そのユニットを単独でテストします。これらのテストを機能させるために1、2か月かかった後、それを隣接するものと統合し、システムの大部分、あるいはシステム全体に対して統合テストを実行できます。重要な違いは、単体テストは私の/私たちのコードを単独でテストするのに対し、統合テストは私たちのコードが別々に開発されたコードとどのように連携するかをテストすることです。

今日、多くの人々が、Kent Beckがエクストリームプログラミングの一環として先駆的に開発したXunitファミリーのテストツールの一環として、単体テストに出会いました。Kentは、開発者が日常業務の一環として記述するテストを示すために「単体テスト」を使用しました。

プログラマーは、プログラムの動作に対する自信をプログラム自体の一部にすることができるように、単体テストを作成します。顧客は、プログラムの動作に対する自信をプログラムの一部にすることができるように、機能テストを作成します。

-- Kent Beck（エクストリームプログラミング入門、第1版）

Kentの最初の定式化では、「単体テスト」は、別のテストチームとは対照的に、プログラマーによって書かれたものを意味することに注意してください。C3で単体テストを作成したとき、通常は単一のクラスの動作に焦点を当てました。しかし、必要なすべての依存関係を持つオブジェクトを作成して、そのメソッドを実行できるようにするテストフィクスチャを設定しました。他のオブジェクトも実行されますが、このテストでは、他のすべてのコードが正しく機能していると想定します（通常、他のコードには独自のテストがあります）。

この「単体テスト」の使い方については、かなりの議論があったことを覚えています。あるテスト専門家は、この用法についてKentを激しく非難しました。私たちは彼に単体テストをどのように定義するかを尋ね、彼の答えは「トレーニングコースの最初の朝に、単体テストの24の異なる定義を説明します」のようでした。

XPに触発された単体テストの初期の頃から、「単体テスト」という用語を嫌い、「マイクロテスト」や「プログラマテスト」などの名前の使用を提案する人々がいました。

多くの人にとって、この最大の課題は、これらの依存オブジェクトでした。注文オブジェクトをテストしていて、それが顧客オブジェクトと連携している場合、顧客オブジェクトのバグが原因で注文オブジェクトのテストが失敗する可能性があります。これは、連携するオブジェクトがモック、スタブ、またはその他のテストダブルに置き換えられる、異なるスタイルの単体テストの作成につながりました。それ以来、これらのスタイルの単体テストを、社交的および孤独的と表現すると便利であることがわかりました。[1]

この区別と絡み合っているのは、私がクラシックとモック主義と呼ぶ、XP単体テストプラクティスの2つの流派の成長です。古典的なXP単体テストは、私たちが最初に使用した社交的なアプローチに従いますが、モック主義スタイルは孤独なテストを好みます。

そこで、ピラミッド対ハニカムに戻りますが、ハニカムや同様の形状の支持者を読んだとき、私は通常、彼らがモックの過剰な使用を批判し、それがもたらすさまざまな問題について話しているのを耳にします。このことから、彼らの「単体テスト」の定義は、私が孤独な単体テストと呼ぶものと specifically に同じであると推測します。同様に、彼らの統合テストの概念は、私が社交的な単体テストと呼ぶものと非常によく似ています。テストピラミッドの説明では、単体テストは社交的および/または孤独的であると見なされているため、これはピラミッド対ハニカムの議論を moot にします。

この意味論的な図は、「単体テスト」を厳密に定義しているように見える統合テストの定義によって、さらに曖昧になっています。ここでのポイントは、誰かがさまざまなテストカテゴリについて話し始めたら、彼らの言葉が何を意味するのかを深く掘り下げることです。なぜなら、彼らはおそらくあなたが最後に読んだ人と同じようにはそれらを使用していないからです。

あなたが私の注意深い散文に適切な注意を払っているなら、私は以前に、単体テストと統合テストについてのこの明確さの欠如は、私がハニカム/ピラミッドの議論で抱えている2番目に大きな問題だと言ったことに気付くでしょう。私の最大の懸念は、次の引用によってうまくまとめられています。

人々は、どのタイプのテストを何パーセント書くべきかについて議論するのが大好きですが、それは注意をそらすものです。明確な境界線を確立し、迅速かつ確実に実行され、有用な理由でのみ失敗する表現力豊かなテストを作成するチームはほとんどありません。代わりにそれに焦点を当ててください。

-- Justin Searls

---