我一直在听说测试驱动开发（TDD）的伦敦风格与芝加哥风格（有时称为底特律风格）。
犹他州极限编程用户小组工作坊：
交互风格的 TDD 在伦敦的Extreme Tuesday俱乐部流行后也被称为嘲笑风格，或伦敦风格。通常将其与底特律风格或传统的 TDD 形成鲜明对比，后者更加基于状态。
该讲习班既涵盖了芝加哥的TDD 学校（基于状态的行为测试和三角测量），也涵盖了伦敦的伦敦学校，后者更侧重于交互测试，模拟和端到端TDD，尤其着重于责任驱动设计和Steve Freeman和Nat Pryce的出色的《不断增长的面向对象的软件，由Tests引导》一书最近重新采用了“告诉，不要问”的面向对象方法。
张贴经典TDD还是“伦敦学校”？杰森·戈尔曼（Jason Gorman）的著作很有帮助，但他的例子使我感到困惑，因为他使用两个不同的例子，而不是两种方法都使用一个例子。有什么区别？您何时使用每种样式？
Answers:
假设您有一个名为“ ledger”的类，一个名为“ calculate”的方法，该方法使用“ Calculator”根据传递给“ calculate”的参数进行不同类型的计算，例如“ multiply（x，y）”或“ subtract（ x，y）”。
现在，假设您要测试调用ledger.calculate（“ 5 * 7”）时发生的情况。
伦敦/互动学校会让您断言是否调用了Calculator.multiply（5,7）。各种模拟框架对此很有用，例如，如果您没有“ Calculator”对象的所有权（假设它是无法直接测试的外部组件或服务，但是您确实有此所有权，则可以使用）知道您必须以特定方式致电）。
芝加哥/州立学校会让您断言结果是否为35。jUnit / nUnit框架通常适合于这样做。
两者都是有效且重要的测试。
Calculator回归multiply，您将看到两个测试失败：分类帐测试和计算器测试，但是如果您模拟计算器，则只有一个测试失败。这样可能更容易查明错误的来源，尤其是在系统很复杂的情况下。
Martin Fowler 的文章Mocks Are n't Stubs很好地介绍了该主题。
根据您选择的设计样式（以及构建程序所依据的设计原则），至少有两种查看对象的方式：
在第一种情况下，您会对处理产生的结果或处理后对象处于哪种状态感兴趣。这是assertEquals()输入图片等方法的地方。在这种情况下，处理中还涉及其他什么对象，调用哪些方法等都无关紧要。这种验证称为基于状态的验证，是“经典”样式。
在第二种情况下，由于大多数对象甚至都没有返回任何结果（例如voidJava中的方法），因此您对对象之间如何通信以及在测试所施加的情况下它们是否传递正确的消息更加感兴趣。这些交互通常在模拟框架的帮助下进行验证。这种验证称为基于行为的验证或基于交互的验证。它的含义之一是称为行为驱动开发的技术，通过该技术，您可以假设一个类的协作者已经存在（即使它们可能不存在）来开发一个类，因此您可以针对其接口进行编码。
请注意，这不是一个选择。您可以设计一种风格，将两种方法结合在一起，以充分利用每种方法的优点。