単体テストの定義

最近、インターネットでTDDが現在生きているかどうか、それが必要かどうか、どのような形であるかについて深刻な騒動があります。 それはすべて、David Hanson の記事「TDDは死んでいます。 その後、多くの著者による記事と、David、Kent Beck、Martin Fowlerとのハングアウトなど、この問題に関する活発な議論が行われました（ところで、次のハングアウトは明日、5月16日です）。



しかし、同じMartin Fowlerがユニットテスト（ bliki：UnitTest ）の定義を試みた数日前に、その翻訳を以下に示します。 そして翻訳後、この主題についての私の考えがいくつかあります。



-

ソフトウェア開発の世界では、彼らはユニットテストについてよく話します。私はプログラマーとしてのキャリアを通してこの概念に精通しています。 しかし、ソフトウェア開発の世界の他の多くの用語と同様に、この用語は非常に不十分に定義されており、開発者が実際よりも厳密な定義を持っていると考えると混乱することがよくあります。







ユニットテストを頻繁に使用していましたが、最終的なコミットメントは、Kent BeckとテストツールのxUnitファミリの使用を開始したときに始まりました。 （時々、「xunitテスト」という用語がこのタイプのテストにより適しているようにさえ思えます。）ユニットテストは、 エクストリームプログラミング （XP）でも重要なアクティビティになり、 テストを通じて迅速に開発されました （TDD-テスト駆動開発）。



XPでの最初からの単体テストの役割は、いくつかの懸念を引き起こしました。 usenetグループでのテストの専門家が、「ユニットテスト」という用語の誤用でXPの支持者をscった議論をはっきりと覚えています。 私たちは彼の定義を求めましたが、彼は次のように答えました。「私のテストコースの最初に、ユニットテストの24の異なる定義を検討します。」



意見の相違にもかかわらず、いくつかの側面で私たちの視点は収束しました。 第一に、単体テストは低レベルであり、ソフトウェアシステムのごく一部のみに焦点を合わせるという考え方があります。 第二に、今日の単体テストは通常​​、開発者が通常のツールを使用して作成され、それにテストフレームワーク（*）が追加されます。 第三に、単体テストは他のタイプのテストよりも大幅に高速になると予想されます。

しかし、見解には違いがありました。 モジュールと考えられるものには異なる視点があります 。 オブジェクト指向設計では、モジュールはクラスと見なされます;手続き的および機能的なアプローチでは、関数はモジュールと見なされます。 実際、これは状況に応じた概念です。チームは、システムを理解したりテストしたりするためのモジュールとして考慮すべきものを決定します。 また、クラスはモジュールであるという考えから始めますが、よく密接に関連するクラスのセットを単一のモジュールと見なし始めます。 あまり一般的ではありませんが、クラスメソッドのサブセットをモジュールと見なすことができます。 実際、この概念をどのように定義するかは重要ではありません。

分離

アプローチのより重要な違いは、テスト中のモジュールを相互作用するオブジェクトから分離する必要があるという質問です。 注文クラスの価格計算方法をテストしているとします。 価格設定メソッドは、製品および顧客クラスのいくつかのメソッドを呼び出します。 相互作用するオブジェクトの分離の原則に従う場合、顧客のクラスのエラーは注文のクラスのテストの低下につながるため、ここでは実際の製品と顧客のクラスを使用したくないでしょう。 代わりに、相互作用するすべてのオブジェクトにテストダブルを使用します。







しかし、すべての開発者が分離を使用するわけではありません。 実際、90年代にxunitテストが開始されたとき、他のオブジェクトとの通信が非常に不便でない限り（リモートクレジットカード検証システムとのやり取りなど）、テストされたクラスを分離しようとしませんでした。 隣接するテストが失敗した場合でも、失敗の本当の原因を理解するのに困難はありませんでした。 したがって、実用的な観点から、孤立の欠如を問題とは考えませんでした。

彼の批判の理由は、まさに「ユニットテスト」の定義における孤立性の欠如でしたが。 単一モジュールの動作をテストするため、「ユニットテスト」の定義が適切だと思います。 このモジュール以外のすべてが正常に動作することを前提に、テストを作成しています。



2000年代にhunitテストが人気を博し始めたとき、少なくとも一部の人々にとって、孤立の概念は再び活気を取り戻しました。 モックをサポートするモックオブジェクトとフレームワークの出現を見てきました。 その結果、xunitテスターの学校が2つあり、それらを古典派と模擬学派と呼びます 。 Moqistsのように、古典派の信奉者は孤立を気にしません。 私は両方の学校のhunitテスターを知っており、尊敬しています（ただし、私は自分で古典派に所属しています）。



複雑な相互作用の存在下で、古典派の代表者（私を含む）でさえ、偽物を使用します（テストダブル）。 偽物は、リモートサービスを操作するときの動作の不確実性を排除するために非常に貴重です。 古典派の一部の代表者は、データベースやファイルシステムなどの外部リソースとのやり取りには偽物を使用する必要があると考えています。 一部はこの意見は不確実な行動のリスク、一部は速度の問題に基づいています。 これは有用な推奨事項だと思いますが、絶対的なルールとは思いません。 リソースへのアクセスが安定しており、十分に高速であれば、単体テストから使用できない理由はありません。

スピード

単体テストには、いくつかの共通のプロパティがあります。小さなスコープ、開発者によって作成され、迅速に実行されます。これにより、開発中に頻繁に実行できます。 実際、これはセルフテストコードの重要な機能の1つです。 この場合、プログラマーはコードの変更後にユニットテストを実行できます。 コードをコンパイルする必要があるたびに、ユニットテストを1分間に数回実行できます。 これは、誤って何かを壊してしまった場合、すぐに知りたいので便利です。 最新の変更で何かを壊した場合、このエラーをすぐに見つける方がはるかに簡単です。



翻訳者の メモ

Kent Beckは、コンパイル中に（場合によってはテストなしで）テストを実行するというアイデアを開発し、連続テスト（Continuous Testing）のアイデアを提案しました。 そのようなツールの例： Mighty-MooseおよびNCrunch for .NET、 JUnit Max for Java。



テストを頻繁に実行する場合、すべてを実行することはできません。 通常、現在作業中のコードで動作するテストのみを実行する必要があります。 この場合、テストの実行期間のために、テストの深さを犠牲にします。 このテストスイートを「コンパイルスイート」と呼びます。これは、Rubyのようなインタープリタ言語でも、コンパイルするたびに実行するためです。



継続的インテグレーションを使用する場合、ステップの1つとしてテストを実行する必要があります。 私がコミットスイートと呼ぶこのテストスイートには、すべての単体テストが含まれている必要があります。 また、いくつかの受け入れテスト（ Broad-StackテストまたはEnd-to-Endテスト ）が含まれることもあります。 開発者として、このテストスイートを1日に数回実行する必要があります。もちろん、バージョン管理システムへの変更をコミットする前に、またそのような機会があれば、休憩中または集会中に実行する必要があります。 一連のコミットテストが速く実行されるほど、実行できる頻度が高くなります（**）。



ユニットテストとそのセットの実行速度については、人によって基準が異なります。 したがって、 David Heinemeier Hanssonにとっては、コンパイルスイートを数秒間実行し 、コミットスイートを数分間実行するだけで十分です。 Gary Bernhardtはこれが遅すぎると見なし、コンパイルセットが約300ミリ秒実行されると主張し、 Dan Bodartはコミットセットが数秒以上完了するのを待ちたくありません。

この質問に対する唯一の正しい答えがあるとは思いません。 個人的には、コンパイルセットが1秒または2、3秒で実行されたときに違いは見られませんでした。 私は、コミットセットを10分以上実行しないというKent Beckの規則が気に入っています。 ここでの主なアイデアは、テストスイートを十分な頻度で実行することを妨げないように、テストスイートを十分に高速で実行することです。 また、「十分な」とは、テストでバグが見つかったときに、少量のコードを掘り当てて、かなり迅速に見つける必要があることを意味します。

注釈

（*）私は「今日」と言います。これはXPのおかげで正確に変わったからです。 新世紀の始まりをめぐる議論の中で、XPの支持者は、一般的に受け入れられている観点はプログラマが自分のコードをテストするべきではないということであるため、非常に批判されてきました。 一部の企業では、開発者コードの単体テストを作成することが唯一のタスクである専門の単体テスターがいました。 この観点の理由は次のとおりです。人々はコードをテストするときに「概念的な盲目」を持っています。 プログラマーは貧弱なテスターなので、プログラマーとテスターの間に何らかの形で対立することは有用です。 XPサポーターの観点は、プログラマーが少なくとも個別の「モジュール」のレベルで優秀なテスターに​​なることを学ぶことができ、テストを作成するために追加のグループを関与させると、テストによって提供されるフィードバックが非常に遅くなるということでした。 XUnitツールは、テスト作成のオーバーヘッドを最小限に抑えるために特別に開発されたため、この点で非常に重要な役割を果たしました。



（**）実行時間がコミットテストの期間よりも長い有用なテストがある場合、 展開パイプラインを構築し、これらのテストをパイプラインの後半のステージに配置する必要があります。



-



この記事では、マーティンはコードとテストの作成の問題に意図的に対処せず、代わりに単体テストの定義を提供し、モジュールの概念に関するさまざまな視点の存在を、分離と実行の速度の必要性について示しようとします。



私自身は、ユニットテストが他の世界から完全に隔離されたクラスをテストするべきだという意見に出くわしました。 たとえば、ロバート・マーティンが著書「Principles、Patterns、and Agile Development Techniques」で説明しているのはこのアプローチであり、「依存関係逆転の原理に関する批判的な見方」という記事でそれを批判しました。



私の理解では、動作が決定論的で高速であれば、単体テストで特定のクラスを使用してもまったく問題はありません。 不要な依存関係を強調すると、クラスのカプセル化が損なわれ、その結果、システムの理解と保守が容易になりません。 安定した依存関係はすべて直接使用でき、使用する必要があります。また、動作が決定的ではない「可変」依存関係のみを区別する必要があります。



私はユニットテストの古典派のサポーターであり、非決定的な外部リソースにアクセスしない場合、実際のクラスを使用する必要があると思います。 私の理解におけるmokaの豊富さの問題は、受け取ったテストがテスト環境に依存しすぎてテスト環境が脆弱になり、インターフェースと間接性の豊富さがシステムの「理解しやすさ」を悪化させ、99％のケースでは必要ない柔軟性を追加することです。

もちろん、mokaの使用に関する他の観点もあります。 したがって、スティーブ・フリーマンとナット・プライスの著書「Growing Object-Oriented Software Guided by Tests」では 、別の視点が取られています。 ただし、同時に、テストのダウンタイムを注意深く監視し、テストの各行にmoqの5行の初期化が来る状況を許可しません。



2つのキャンプのいずれかに固執することは絶対に普通です：クラシックまたはモッキスト。 主なものは、あなたの選択が意識的であり、あなたのテストが開発と保守を簡素化し、これを妨げないことです。