问单元测试--它实际上增加了多少时间？

EN

我会说两倍的时间是一个公平的估计，是的，单元测试总是值得的时间和努力。

然而，我认为花在单元测试上的时间要比以后调试和修复由于缺乏单元测试而导致的错误所花费的时间要少得多。

为应用程序编写(编码)

单元测试可以有效地将项目所需的开发时间提高一倍。

如果你只计算输入代码的时间，那么写测试肯定比不写测试要慢。然而，如果你在没有测试安全网的情况下考虑到破坏现有功能-调试-修复的时间因素，那么除了琐碎的项目之外，收益通常会超过任何成本。测试通过设计(TDD) +防御(回归)+文档(规范)为您提供帮助。

这是真的吗，尤其是对于初学者？

那得看情况。套用Beck的话(我想)，如果你是个笨蛋，工具/冰毒不会对你有帮助，如果你是个编程之神，你可能不需要它们。然而，对于我们中间的大多数人来说，这是有帮助的。当你朝着那个光谱的右边移动时，事情变成了你的第二天性，你将“看到”即将到来的事情，所花费的时间开始减少(尽管不是0)。为了避免犯新手错误，找一个已经在那里工作过的人(从邮件列表中寻求帮助，或者暂时雇佣一个好教练)

还提出了一些后续问题(布朗尼要点)：如果您正在做一个客户项目，并在完成后移交，那么是否值得花费时间和精力进行单元测试？

即使下一个团队放弃了测试套件，我仍然会这样做，以保持我的生产力，并减少花在创建和跟踪bug上的时间。

如果您使用的是TDD，则不会，因为：

，

• ，你实际上是先写测试。这本身就节省了大量的时间，因为你已经准备好了你要做的事情。您还可以确切地知道何时停止编码。(当测试通过时)
• 当你实际编写代码时，它会尽可能地小。您可以在通过测试时停止编码，然后只要测试仍在通过，您就可以信心十足地使其变得更好。
• 然后为边缘情况编写测试(如果有必要)，并检查是否会出现问题。

我这样做了，发现这实际上减少了开发时间-因为你甚至在开始编写实际代码之前就已经考虑到了你想要做什么，并且你知道当你完成它时，它实际上是有效的。