单元测试的价值答案

【问题标题】：The Value of Unit Testing单元测试的价值
【发布时间】：2009-04-02 02:17:28
【问题描述】：

每当我提出将单元测试和代码覆盖率作为开发周期不可分割的一部分的重要性时，我从经理/老板那里得到的一些典型答案（按陈词滥调的升序排列）

“这是 QA 的工作，只关注功能和开发”
“应用程序不是关键任务，如果有一些错误也不是世界末日”
“我们不能花时间在单元测试上”
“尽量不要太花哨”

尽管有做好工作的最佳意图，但最终到了责备游戏的时候，负担最终落在了开发者身上。

我经常看到生产中出现问题，其中一些问题可以通过运行单元测试静态捕获这些错误来避免。

我只是想进行一次对话，以了解人们的经历以及解决此问题的最佳方法是什么。

更新：感谢大家提供很多有见地的建议。我希望我可以选择几个答案作为正确答案。

【问题讨论】：

这确实是一个非常好的问题。实际上，这是 SO 最好的问题之一。
Is Unit Testing worth the effort? 的可能重复项
查看我的答案，您现在可能想更改哪个答案是最好的 :)。实际记录的证明，而不是继承人的说法。

标签： c# .net unit-testing

【解决方案1】：

在开发过程中引入单元测试就像投资：您必须先投入一些资金才能在以后获得利润。如果你坚持下去，管理层应该更加注意这个类比：描述需要哪些投资，然后制定利润计划。

例如：投资：

实施测试所花费的时间基础设施（没有严肃的产品单元测试可以在没有特定于测试的基础架构代码简化产品特定的测试模式，测试数据创建/删除等）；
花在编写实际测试上的时间；
花在审查和支持测试；
等

利润：

没有任何错误会在没有标志的情况下再次出现；
没有单元测试通过就不会发布主要功能；
大多数错误的周期 development-qa-fix bugs 减少了一半：development-unit test-fix bugs；
等

【讨论】：

【解决方案2】：

大多数经理在看到单元测试的实际意义之前不会看到单元测试的优势，所以我的建议是，根据经验，采取以下步骤：

将单元测试应用于重复出现的错误 - 这是证明单元测试价值的最佳用例。当你有 bug 出现并在其他构建中重新出现时，单元测试将允许开发人员查看哪些更改导致了 bug，除了提前提醒他们修复是有序的。这也很容易向管理层展示。
将单元测试应用于常规错误 - 现在清楚地证明了单元测试的有用性，几个反复出现的错误在长期内消失的实例应该足以鼓励每个人使用单元测试来评估所有错误，以防止它们成为重复出现的错误。
将单元测试应用于新功能 - 通过单元测试确保旧错误不会再次出现，并确认它们首先已得到修复，下一步是将其应用于新功能以确保将错误最小化。明确指出不可能完全消除错误。
应用完整的 TDD - 最后一步是在编码之前应用单元测试，作为一种设计工具，既有助于设计代码，又能最大限度地减少错误。

当然我并不是说这很容易——我上面所说的过于简单化了，即使我每天都在挣扎——很难说服所有人。

如果以后您决定跳槽到另一家公司，您可能需要明确地寻找一家实施 TDD 的公司。

【讨论】：

【解决方案3】：

人们倾听他们的钱包。显示通过尽早发现错误可以节省多少时间。将其转化为节省美元。

【讨论】：

+1：无论如何都要进行单元测试。不要浪费时间证明或解释。只要去做，做更好、更便宜的开发。

【解决方案4】：

关于 #3，在单元测试上花费时间很可能会缩短整体上市时间。很棒的文章 - http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html

【讨论】：

【解决方案5】：

对我来说，采用单元测试的最大优势是我可以改变我的编码行为，使其更易于测试，换句话说，以更松散耦合的方式。

如果你在实际项目中因为管理问题不能练习单元测试，我会选择在一些小玩具项目上练习，只是为了强迫自己找到一种方法来编写可测试的代码，即使没有单元测试。

我自己的 2 美分。

【讨论】：

这很好。我在自己的时间编写的代码上练习单元测试，它很震撼。就我个人而言，它帮助我打破了依赖关系并确保我的代码被设计为灵活和可扩展的。没有那个工具可以让我在某些方面陷入困境

【解决方案6】：

如果单元测试，我假设您在这里谈论 TDD，对您来说是否重要，您应该利用自己的时间来编写它们（假设您有时间）。如果你这样做了，请记录下你实际花费了多少时间来编写它们，并且在它们已经到位一两个发布周期之后，带着一些数据去找你的经理。

如果您发布的答案确实是您的经理所说的，那么您为白痴工作，也许一些硬数据会影响他们。鉴于市场情况，辞职不太可能，玩办公室政治不会让你有任何收获（或提高代码质量）。

除非您的经理明白 TDD 不仅仅是只是为了防止错误或“测试”，否则他们永远不会得到它。 TDD 是关于设计和整体代码质量的。

你必须向他们展示。如果他们不能被说服，那么我会开始寻找。安静;)

【讨论】：

+1 - 我不确定他是否真的在谈论引入 TDD 本身。不过，我很高兴你这样做了。
马克是对的。我不是特别指 TDD。只是单元测试代码的想法

【解决方案7】：

我的简短和不完整的建议是：

只是换工作。一家经理给出这种答案的公司无论如何都会失败，而且很快就会失败。在为时已晚之前离开。
扭转指责游戏。每次发布没有经过单元测试的东西时，都要发表官方声明，说明它已经完成了，并且你不能保证它没有错误。
记下您在任务上花费的时间，在部署失败后单独修复错误，并将其与编写单元测试的（潜在）时间分配相加。
李>

【讨论】：

+1 只是换工作，但也要确保你的管理层和你的（前）同事知道你为什么这样做。不要“启用”白痴经理。

【解决方案8】：

您为什么不为您的代码编写单元测试？不知道有没有其他开发者有同样的问题？可能他们也会按照您的示例编写单元测试。

我认为问题不在于集成服务器的技术或成本。问题在于管理层对单元测试的态度。因此，请与所有开发人员一起说服他们。

这个帖子有很多提示（Jon Limjap's answer），试试吧！

【讨论】：

【解决方案9】：

不要以特定方法推销管理；这会很困难，而且不会真的给你买太多东西。您的管理链是否欣赏单元测试代码并不重要。

当然，对代码进行单元测试有很多好处，但不要依赖管理层的认可来编写测试。当人们开始看到结果时，他们会涌向 The Right Thing。

【讨论】：

【解决方案10】：

在此线程上的其他优秀 cmets 中添加另一个想法（其中许多我已投赞成票）：确保您的管理层知道此时单元测试是高度自动化的。我发现在屏幕上弹出 NUnit，点击“全部运行”按钮并看到几十个绿灯测试在几秒钟内通过，这让我印象深刻。这样做一次，说“这证明了我所有的旧工作仍然是正确的，尽管我做了所有新的更改”，你可能会赢得一些转换。无论如何，他们会更加信任你——通过你可见的质量证明——超过他们对他人的信任。这只会对你的职业生涯有好处。

【讨论】：

我确实尝试过，在一个实例中使用单元测试来寻找性能。问题并修复它们，使用传统开发即使不是不可能也很难。技巧。在很大程度上，这是工作文化。一起拍一些东西，然后继续下一件事。实时修复破损！
哇，真的很伤心。如果您决定在其他地方寻找更好的工作，祝您好运！

【解决方案11】：

经典的回答是，越早发现错误，修复的成本就越低，我认为大多数经理都可以理解这一点。

正如 Mark 所说，展示一些具体的东西是让 PHB 相信某些东西是好的最好方法，因为他们习惯于听谈话并且可能不知道单元测试和其他测试之间的区别。

【讨论】：

@Anders - “不知道单元测试和其他测试的区别”。这是真的。今天，当一个 PHB 证明 QA 测试足以测试我正在开发的框架时，我陷入了一场争论！一个真正的开发人员会对这个答案感到畏缩。呜呜呜……

【解决方案12】：

现在有资源可以提供帮助。现代用例列表，TDD 的切实证据。

您是否需要让您的老板或队友相信 TDD 正在被使用？这不是什么理论？那不只是继承人的说法吗？

现在您可以查看WeDoTDD.com，查看 TDD 的公司列表以及这些团队背后的故事。

这正是我创建这个网站的原因，以平息围绕“TDD 证明”和“TDD 是否有效”和“谁在做 TDD”的争论。

您还可以通过阅读这些公司背后的故事和实践该主题的团队来了解有关该主题本身的很多信息。

【讨论】：