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

Question

阅读对这个问题的回答 Disadvantages of Test Driven Development?我的印象是对 TDD 是什么以及它应该如何进行存在很多误解。在这里解决这些问题可能会被证明是有用的。

Answer 1

我觉得被接受的答案是最弱的答案之一( Disadvantages of Test Driven Development? )，而最先进的答案闻起来像是一个人可能正在写特定的测试。

Big time investment: for the simple case you lose about 20% of the actual implementation, but for complicated cases you lose much more.

TDD 是一种投资。我发现一旦我完全进入TDD，我失去的时间非常少，而且我失去的时间比维护时间多得多。

For complex cases your test cases are harder to calculate, I'd suggest in cases like that to try and use automatic reference code that will run in parallel in the debug version / test run, instead of the unit test of simplest cases.

如果您的测试变得非常复杂，那么可能是时候检查您的设计了。 TDD 应该引导您走上更小、更简单的代码单元协同工作的道路

Sometimes you the design is not clear at the start and evolves as you go along - this will force you to redo your test which will generate a big time lose. I would suggest postponing unit tests in this case until you have some grasp of the design in mind.

这是他们最糟糕的一点! TDD 真的应该是“测试驱动 设计 ”。 TDD 是关于设计，而不是测试。要充分实现TDD的好处值(value)，你有玩具 驱动器 你的设计来自你的测试。所以你应该重做你的生产代码来让你的测试通过，而不是相反，正如这一点所暗示的

现在更新最多的: Disadvantages of Test Driven Development?

When you get to the point where you have a large number of tests, changing the system might require re-writing some or all of your tests, depending on which ones got invalidated by the changes. This could turn a relatively quick modification into a very time-consuming one.

就像第一点接受的答案一样，这似乎是测试中的过度规范以及对 TDD 过程的普遍缺乏了解。进行更改时，请从测试开始。更改新代码应该做什么的测试，并进行更改。如果这种变化破坏了其他测试，那么你的测试正在做他们应该做的事情，失败了。对我来说，单元测试是为了失败而设计的，因此为什么 RED 阶段是第一位的，并且永远不应错过。