代码之家 › 专栏 › 技术社区 › pete the pagan-gerbil

你如何用TDD设计复杂的系统?

tdd unit-testing

11

pete the pagan-gerbil · 技术社区 · 15 年前

类似 Does TDD mean not thinking about class design? 我很难思考传统的“设计”阶段在TDD中的位置。

根据保龄球游戏kata(“对话”版本,我现在不知道它的链接),tdd似乎忽略了早期的设计决策(丢弃框架对象、滚动对象等)。我可以在这个例子中看到,遵循测试并忽略你最初的设计思想是一个好主意,但是在更大的项目或那些你想为扩展/定制留一个空间的项目中,把你没有测试或不需要立即测试的东西放进去是不是更好,以避免耗时的Rewr后来呢?

简而言之——在做TDD时,有多少设计是太多的,在编写测试和代码以通过测试时,我应该遵循该设计多少(忽略我的设计,只担心通过测试)?

或者我不担心什么,而仅仅为了跟踪测试而编写的代码是不 (在实践中)如果你被画成一个角落,很难重写或重构? 另外,我是否错过了重点,我应该期望当我开始测试新的功能部分时重写部分代码?

4 回复 | 直到 8 年前

1

9

dr. 15 年前

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

TDD的一部分是重构。

2

7

Dinuk 8 年前

关于“设计大型复杂系统”,有一些话不能与TDD相联系。- 尤其地 当TDD被解释为“测试驱动设计”而不是“测试驱动开发”时。

在“开发”的上下文中,使用TDD将确保您正在编写 可测试的 提供TDD所引用的所有好处的代码(早期检测错误、高代码:测试覆盖率、更容易将来重构等)

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

(工程设计)性能
安全性
可扩展性
可利用性
(以及所有其他“能力”)

(也就是说,上述所有问题都不会神奇地通过“首先编写失败的测试用例,然后是工作实现、重构-起泡、漂洗、重复…”方法“浮现”。

对于这些,您将需要通过白板来处理问题,白板是系统的高级细节,然后是关于需求和问题空间所施加的约束的低级细节。
上面的一些考虑因素相互竞争,需要谨慎的权衡,而这些权衡不会通过编写大量的单元测试“出现”。
一旦确定了关键组件及其职责,以及可以理解,TDD可用于 这些措施的实施组件 . 重构和持续的过程审查/改进您的代码将确保低级别的设计这些组件的细节都是精心制作的。

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

另外,检查以下内容 videos on Architecture 这给思维过程增加了很多常识。

3

philant 15 年前

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

必须注意、倾听和嗅探代码,以检测重构机会和代码气味。

严格遵守TDD和 SOLID principles 将带来干净、可测试和灵活的代码,以便可以轻松地重构,利用单元测试作为脚手架来防止回归。

4

2

Lunivore 15 年前

我发现了三种使用TDD进行设计的方法:

允许设计在消除重复和复杂性时自然出现
在前面创建一个完美的设计,使用模拟与单一责任原则相结合
要实事求是。

实用主义在大多数时候似乎是最好的选择,下面是我要做的。如果我知道某个特定的模式非常适合我的问题(例如,MVC),我将直接进行模拟,并假定它是有效的。否则,如果设计不那么清晰,我就允许它出现。

我认为需要重构一个紧急设计的交叉点就是它停止容易改变的点。如果一段代码设计得不完美,但另一个开发人员发现它可以很容易地自己重构,那么这就足够好了。如果代码变得如此复杂,以致于它不再对其他开发人员明显,那么是时候重构它了。

我喜欢真正的选择,重构一些完美的东西让我感觉就像在设计中承诺而不需要这样做。我改为重构为“足够好”;这样,如果我的设计证明自己是错误的,我就不会浪费时间。假设您的设计是错误的,如果您以前从未在类似的上下文中使用过它。

这也让我比完美的代码更快地得到我的代码。说了这句话,正是我努力使代码完美,才教会了我行在哪里!