关于TDD有哪些常见的误解？

阅读对这个问题的回答测试驱动开发的缺点？我的印象是,对TDD是什么以及应该如何进行有很多误解.在这里解决这些问题可能有用.

我觉得接受的答案是最弱的(测试驱动开发的缺点？)之一,以及可能正在编写指定测试的人的最新修改的答案气味.

大量投资:对于简单的情况,你会失去大约20%的实际实施,但对于复杂的情况,你会失去更多.

TDD是一项投资.我发现,一旦我完全进入TDD,我失去的时间非常少,而且当我到达维持时间时,我失去的时间多于弥补.

对于复杂情况,您的测试用例难以计算,我建议在这种情况下尝试使用在调试版本/测试运行中并行运行的自动参考代码,而不是最简单情况的单元测试.

如果您的测试变得非常复杂,可能是时候审查您的设计了.TDD应该引导您沿着更小,更简单的代码单元协同工作

有时候你的设计在开始时并不清晰,并随着你的进展而发展 - 这将迫使你重做你的测试,这会产生很大的时间损失.在这种情况下,我建议推迟单元测试,直到你对设计有所了解为止.

这是他们所有人中最糟糕的一点!TDD应该是"测试驱动设计 ".TDD是关于设计,而不是测试.为了充分实现TDD的优势价值,您可以通过测试来玩具驱动您的设计.因此,您应该重做生产代码以使测试通过,而不是像这一点所暗示的那样

现在目前最高调的是:测试驱动开发的缺点？

当您达到大量测试的程度时,更改系统可能需要重新编写部分或全部测试,具体取决于哪些测试因更改而失效.这可能会将相对快速的修改变成非常耗时的修改.

就像接受的答案第一点一样,这似乎超出了测试中的规范,并且普遍缺乏对TDD过程的理解.进行更改时,请从测试开始.更改新代码应执行的测试,并进行更改.如果该更改破坏了其他测试,那么您的测试正在做他们应该做的事情,失败.对我来说,单元测试的目的是失败,因此为什么RED阶段是第一阶段,永远不应该错过.

恕我直言TDD最大的误解是:编写和重构测试所花费的时间会浪费时间.这个想法就像"是的,测试套件很好,但如果我们编写代码就会更快完成这个功能".

如果处理得当,编写和维护测试的时间会在项目生命周期内多次保存,而不会花费在调试和修复回归上.由于测试成本是预先确定的,并且随着时间的推移而产生回报,因此很容易被忽视.

其他一些重大误解包括忽略TDD对设计过程的影响,而没有意识到"痛苦的测试"是一种需要快速修复的严重代码味道.