阅读对这个问题的回答Disadvantages of Test Driven Development?我得到的印象是，对于什么是TDD以及应该如何进行，存在很多误解。在这里解决这些问题可能有用。
答案 0 :(得分：13)
我觉得接受的答案是最弱的（Disadvantages of Test Driven Development?）之一，以及最有可能回答特定测试的人的回答。
TDD是一项投资。我发现，一旦我完全进入TDD，我失去的时间非常少，而且我失去的时间远远超过维持时间。大时间投资：简单 如果你失去了实际的20％左右 实施，但对于复杂 你失去更多的情况。
对于复杂的情况，您的测试用例是 更难计算，我建议 尝试使用的案例 将运行的自动参考代码 在调试版中并行/ 测试运行，而不是单元测试 最简单的案例。
如果您的测试变得非常复杂，可能是时候审核您的设计了。 TDD应该引导您沿着较小，较不复杂的代码单元一起工作
有时候你的设计在开始时并不清晰，并随着你的进展而发展 - 这将迫使你重做你的测试，这会产生很大的时间损失。在这种情况下，我建议推迟单元测试，直到你对设计有所了解为止。
这是他们所有人中最糟糕的一点！ TDD应该是“测试驱动设计”。 TDD是关于设计，而不是测试。为了充分实现TDD的好处，您可以在测试中玩具驱动您的设计。因此，您应该重做您的生产代码以使您的测试通过，而不是相反，因为这一点建议
现在最新修改版：Disadvantages of Test Driven Development?
当您进入大量测试时，更改系统可能需要重新编写部分或全部测试，具体取决于哪些测试因更改而失效。这可能会将相对较快的修改变成非常耗时的修改。
就像接受的答案第一点一样，这似乎超出了测试中的规范，并且普遍缺乏对TDD过程的理解。进行更改时，请从测试开始。更改新代码应执行的测试，并进行更改。如果该更改破坏了其他测试，那么您的测试正在做他们应该做的事情，失败。对我来说，单元测试的目的是失败，因此为什么RED阶段是第一阶段，永远不应该错过。
答案 1 :(得分：5)
如果操作正确，编写和维护测试的时间花费在项目的整个生命周期中多次保存 not 花费调试和修复回归。由于测试成本是预先确定的，而且随着时间的推移会产生回报，因此很容易被忽视。
其他重大误解包括忽略TDD对设计过程的影响，并没有意识到“痛苦的测试”是一种需要快速修复的严重代码味道。
答案 2 :(得分：1)
我看到很多人误解了哪些测试对TDD有用。人们编写大型验收测试而不是小型单元测试，然后花费太多时间来维护他们的测试，然后得出结论TDD不起作用。我认为BDD人员完全避免使用单词test。
另一个极端是人们停止进行验收测试，并认为因为他们进行单元测试，他们的代码已经过测试。这又是对单元测试功能的误解。你还需要某种验收测试。
答案 3 :(得分：0)
我经常看到的误解是TDD确保了良好的结果。
通常，测试都是根据有缺陷的要求编写的，因此，开发人员生产的产品不能满足用户的期望。在我看来，TDD的关键是与用户一起定义需求，同时帮助管理他们的期望。
答案 4 :(得分：0)
这些问题在我看来很有争议，因而容易产生误解：
根据我的经验，最大的优势是以编写测试花费大量时间为代价生成更好的代码。因此，对于需要高质量的项目而言，这是非常值得的，但在其他一些质量较差的中心站点上，额外的时间将不值得付出努力。
人们似乎认为只有大部分功能必须经过测试，但这实际上是错误的恕我直言。您需要测试所有内容，以便在重构后测试有效。
TDD的一大缺点是不完整测试给出的错误安全感：我看到网站出现故障，因为人们认为单元测试足以触发部署。
TDD不需要模拟框架。它只是一种以更简单的方式测试某些案例的工具。虽然最好的单元测试在堆栈中被激活，但在代码中的层上应该是不可知的。在这种情况下，一次测试一层是没有意义的。
答案 5 :(得分：0)
只是在锅里拿出另一个答案。
最常见的误解之一是您的代码是固定的，即。我有这个代码，现在我将如何测试它？如果编写测试很困难，我们应该问一个问题：如何更改此代码以便更容易测试？
<强>为什么..吗
那种易于测试的代码是：
如果我们编写这样的代码，那么测试就是一件轻而易举的事。有趣的是，易于测试的代码巧合的是，更好的代码。
更好，更容易阅读，更容易测试，更容易理解，更容易调试。这就是TDD经常被描述为设计练习的原因。