TDDのロンドンとシカゴの学校は何ですか？

テスト駆動開発（TDD）のロンドンスタイルとシカゴスタイル（デトロイトスタイルと呼ばれることもある）について聞いてきました。

ユタ州エクストリームプログラミングユーザーグループのワークショップ：

インタラクションスタイルの TDDも呼ばれmockistスタイル、またはロンドン・スタイルを、それが人気となったロンドンのエクストリーム火曜日クラブの後。通常 は、より状態ベースのデトロイトスタイルまたはクラシック TDDとは対照的です。

ジェイソン・ゴーマンのワークショップ：

ワークショップでは、両方のカバーシカゴ校 TDD（状態ベースの動作テストと三角測量）、とのロンドンの学校に特に重点を置いて、からかうとエンドツーエンドのTDD、相互作用のテストにもっと焦点を当て、責任駆動設計とスティーブ・フリーマンとナット・プライスの優れた成長オブジェクト指向ソフトウェアガイド付きテスト本で最近人気を博した、OOへのアプローチをしないでください。

ポストクラシックTDDまたは「ロンドンスクール」Jason Gormanによるものは役に立ちましたが、彼の例は私を混乱させました。なぜなら、彼は両方のアプローチで1つの例の代わりに2つの異なる例を使用しているからです。違いは何ですか？各スタイルをいつ使用しますか？

「計算機」を使用する「計算機」と呼ばれるメソッド「計算機」と呼ばれるクラスがあり、「計算」に渡された引数に応じて異なるタイプの計算を実行するとします。 x、y）」。

ここで、ledger.calculate（ "5 * 7"）を呼び出したときに何が起こるかをテストするとします。

London / Interactionスクールでは、Calculator.multiply（5,7）が呼び出されたかどうかを断言する必要があります。さまざまなモック作成フレームワークがこれに役立ちます。たとえば、「Calculator」オブジェクトの所有権を持っていない場合（非常に便利な場合があります（直接テストできない外部コンポーネントまたはサービスであるが、特定の方法で電話しなければならないことを知っている）。

シカゴ/州立学校では、結果が35であるかどうかを断言する必要があります。jUnit/ nUnitフレームワークは、一般的にこれを行うことを目的としています。

両方とも有効かつ重要なテストです。

Martin Fowlerによる記事Mocks Aren's Stubsは、このトピックの良い紹介です。

選択した設計スタイル（およびプログラムを構築する設計原則）に応じて、オブジェクトを表示する方法は少なくとも2つあります。

1. 入力に基づいて計算を実行するユニットとして。この計算の結果、オブジェクトは値を返すか、その状態を変更できます。
2. メッセージパッシングによってシステム内の他の要素と通信するアクティブな要素として。

最初のケースでは、処理の結果、またはその処理後にオブジェクトが残っている状態に興味があります。これはassertEquals()、写真を入力するなどの方法です。この場合、他のオブジェクトが処理に関係していたか、どのメソッドが呼び出されたかなどは重要ではありません。この種の検証は、状態ベースの検証と呼ばれ、「クラシック」スタイルです。

2番目のケースでは、ほとんどのオブジェクトは結果さえ返さないため（voidJavaのメソッドなど）、オブジェクトが相互に通信する方法と、テストによって課された状況で正しいメッセージを渡すかどうかに関心があります。これらの相互作用は通常、模擬フレームワークを使用して検証されます。この種類の検証は、動作ベースまたは相互作用ベースの検証と呼ばれます。その意味の1つは、振る舞い駆動開発と呼ばれる手法です。これにより、コラボレーターが既に存在すると仮定して（まだ存在しない場合でも）クラスを開発し、インターフェースに対してコーディングできます。

これは、どちらかまたは両方の選択肢ではないことに注意してください。両方のアプローチを組み合わせたデザインスタイルを使用して、それぞれのアプローチを最大限に活用できます。