TDDのロンドンとシカゴの学校とは何ですか？
テスト駆動開発（TDD）のロンドンスタイルとシカゴスタイル（デトロイトスタイルと呼ばれることもあります）について聞いています。
ユタエクストリームプログラミングユーザーグループのワークショップ：
Interaction-style TDDは、 mockist-style 、または London-style とも呼ばれます。人気になったエクストリーム火曜クラブ。通常、 Detroit-style または classic TDDとは対照的で、より状態に基づいています。
ワークショップでは、TDD（状態ベースの行動テストと三角測量）のシカゴスクールと、ロンドンスクールの両方に焦点を当てています。 Responsibility-Driven Design と Tell、Do n't Ask に特に重点を置いた、相互作用テスト、モック、エンドツーエンドTDD [〜＃〜] oo [〜＃〜] へのアプローチは最近、Steve FreemanとNat Pryceの優れた Growing Object-Oriented Software Guided by Tests /によって再人気化されました本。
Jason Gormanによる投稿 Classic TDDまたは "London School"？ は役に立ちましたが、彼の例は私を混乱させました。両方のアプローチの1つの例ではなく、2つの異なる例。違いは何ですか？それぞれのスタイルをいつ使用しますか？
たとえば、「calculator」を使用して「calculate」に渡された引数に応じてさまざまなタイプの計算を行う「calculate」と呼ばれる「ledger」というクラスがあるとします。たとえば、「multiply（x、y）」や「subtract（ x、y） "。
ここで、ledger.calculate（ "5 * 7"）を呼び出したときに何が起こるかをテストするとします。
ロンドン/インタラクションスクールでは、Calculator.multiply（5,7）が呼び出されたかどうかをアサートします。さまざまなモックフレームワークがこれに役立ちます。たとえば、「Calculator」オブジェクトの所有権がない場合に非常に役立ちます（直接テストできない外部コンポーネントまたはサービスであると想定しますが、特定の方法で呼び出す必要があることを確認してください）。
シカゴ/州の学校では、結果が35かどうかをアサートする必要があります。jUnit/ nUnitフレームワークは、通常、これを行うことを目的としています。
どちらも有効で重要なテストです。
Martin Fowlerによる記事 Mocks Are n't Stubs は、このトピックの良い紹介です。
選択する設計スタイル（およびプログラムを構築する際の設計原則）に応じて、オブジェクトを表示する方法は少なくとも2つあります。
- 入力に基づいて計算を実行するユニットとして。この計算の結果として、オブジェクトは値を返すか、その状態を変更できます。
- メッセージパッシングによってシステム内の他の要素と通信するアクティブな要素として。
最初のケースでは、処理の結果、またはオブジェクトがその処理後に残っている状態に関心があります。これは、assertEquals()などのメソッドが画像を入力する場所です。この場合、他のどのオブジェクトが処理に関与したか、どのメソッドが呼び出されたかなどは問題になりません。この種の検証は、状態ベースの検証と呼ばれ、「クラシック」スタイルです。
2番目のケースでは、ほとんどのオブジェクトは結果も返さないため（たとえば、Javaのvoidメソッド）、オブジェクトが相互に通信する方法、およびオブジェクトが課された状況で適切なメッセージを渡すかどうかに関心があります。テストによって。これらの相互作用は通常、モックフレームワークを使用して検証されます。この種の検証は、行動ベースまたは相互作用ベースの検証と呼ばれます。その影響の1つは、ビヘイビアドリブン開発と呼ばれる手法です。これにより、コラボレーターがすでに存在していると仮定して（まだ存在しない場合でも）クラスを開発し、そのインターフェースに対してコーディングできます。
これはどちらか一方の選択肢ではないことに注意してください。両方のアプローチを組み合わせてそれぞれを最大限に活用するデザインスタイルを設定できます。