如何使用TDD设计复杂系统？

Question

类似于TDD是否意味着不考虑班级设计？，我很难思考传统的“设计”阶段在哪些方面适合TDD。

根据保龄球游戏卡塔(‘对话’版本，其链接逃离我目前)，TDD似乎忽略了设计决策早期(丢弃帧对象，滚动对象，等等)。在这个例子中，我可以看到一个好主意，那就是遵循测试，忽略最初的设计思想，但是在更大的项目中，或者在那些你想为扩展/定制留出一个空缺的项目中，如果你没有测试或者不需要立即进行测试，这样做不是更好吗？

简而言之，在执行TDD时，有多少设计是太多的，在编写测试和通过测试的代码时，我应该遵循多少设计(忽略我的设计，只关心通过测试)？

或者我什么都不担心，如果你被画到了墙角，仅仅为了遵循测试而编写的代码(在实践中)并不难重写或重构？或者，当我测试一个新的功能部分时，我是否遗漏了重点，我应该期望重写部分代码？

Answer 1

我会把你的测试建立在你最初的设计之上。在许多方面，TDD是一个发现过程。您可以期望确认您的早期设计选择，或者发现您可以做出更好的选择。做更多的前期设计，因为你是舒适的。有些人喜欢坐在椅子旁边，做高层次的设计，用TDD来充实设计。而其他人则喜欢先把所有的东西都写在纸上。

TDD的一部分是重构。

Answer 2

关于“设计大复杂系统”有一些不应该与TDD相关联的东西--特别是当TDD被解释为“测试驱动设计”而不是“测试驱动开发”时。

在“开发”的上下文中，使用TDD将确保您正在编写可测试的代码，这些代码提供了TDD的所有优点(早期发现bug，高代码:测试覆盖率，未来更容易重构等等)。

但是在“设计”大型复杂系统时，TDD并没有特别解决系统架构中固有的以下问题

1. (工程)性能
2. 安全性
3. 可扩展性
4. 可用性
5. (及所有其他“隐秘”)

(也就是说，上面提到的所有问题都不能神奇地通过“先写一个失败的测试用例，然后是工作实现，重构-泡沫，漂洗，重复……”而出现.食谱)。

• 对于这些，您将需要通过白板处理系统的高级别和低级别的细节来解决问题，这些细节涉及到需求和问题空间所施加的约束。
• 上面的一些考虑因素相互竞争，需要谨慎的权衡，而这种权衡并不是通过编写大量单元测试而“出现”出来的。
• 一旦定义和理解了关键组件及其职责，就可以在这些组件的实现中使用TDD。重构和不断检查/改进代码的过程将确保这些组件的低级别设计细节是精心设计的。

我还没有遇到一个非常复杂的软件(例如编译器、数据库、操作系统)，它是用测试驱动的设计风格完成的。下面的博客文章非常好地讨论了这一点(编译器，TDD，掌握)

另外，检查下面的建筑录影带，它为思维过程增加了许多常识。

Answer 3

从一个粗略的设计思想开始，选择第一个测试并开始编码，在测试之后进行绿色测试，让设计出现，无论是否与最初的设计相似。初始设计的多少取决于问题的复杂性。

一个人必须注意，倾听和嗅探代码，以检测重构机会和代码气味。

严格遵循TDD和固体原理将带来干净、可测试和灵活的代码，这样就可以轻松地重构它，利用单元测试作为脚手架防止回归。