TDD和责任驱动设计 - 如何协调测试优先与设计过程？

Question

TDD的“伦敦风格”建议关注对象角色，职责和协作，使用模拟对象在自上而下的过程中驱逐大规模组件设计层（而不是专注于算法细化的'经典风格'方法）。

我理解基本方法，但我想知道你如何调和这种形式的TDD（它仍然强调首先编写测试）与我们设计组件的更自然的方式，即。在我们开始编写任何代码之前，草拟相关类的逻辑设计并在纸上/我们的头脑中定义它们的角色和职责。

欣赏一些现实世界的建议。

Answer 1

我认为不需要将TDD（任何形式）与“自然”组件设计协调一致。测试意味着您已经了解了测试的内容，至少您拥有一定程度的精度接口。从粗粒度组件定义开始对我来说似乎非常“自然”。

Answer 2

：）

'伦敦风格'基本上是优秀的OOP与Outside-in（验收测试）驱动的TDD相结合（我假设你的意思是类似于the GOOS book的方法）。 这就是它“应该”完成的方式;虽然“古典”人应该更加明确。我不确定从业者之间是否存在这样的分类（尽管有些人对TDD更快，而且有人为之奋斗）。 基于状态和基于交互的是样式，并不是适合所有尺寸的方法。您需要为手头的任务选择风格。

“在角落里进行TDD”的问题在于，您最终可能会使用经过良好测试的代码，但从客户的角度来看仍然会出错。

Evolution已经让我们进入了一个ATDD循环，这个循环是在客户/接受级别完成的TDD，它驱动开发人员进行验收测试的内部TDD周期。

关于“协调”： 一旦你调整了耳朵，我就发现'听测试'非常有启发性。让测试驱动设计。
这也与BDD人员保持一致。我建议在本书的第一部分中选择the RSpec book，其中有一个演练。