C# 单元测试的价值

下面是一些典型的答案（按陈词滥调的升序排列），每当我提到单元测试和代码覆盖作为开发周期的一个组成部分的重要性时，我都会从经理/老板那里得到

“这是QA的工作，只需关注功能和开发”

“该应用程序不是任务关键型的，如果有一些bug，那也不是世界末日”

“我们负担不起花时间进行单元测试”

“尽量不要太花哨”

尽管有做好工作的最佳意图，但在一天结束时，当责任游戏到来时，负担最终落在开发者身上

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

我只是想和大家谈谈，看看人们的经历是怎样的，解决这个问题的最好方法是什么

---

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

人们听他们的钱包。展示通过尽早捕获bug可以节省多少时间。将其转化为美元储蓄

关于#3，在单元测试上花费时间很可能会缩短整体上市时间。伟大的文章-

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

如果由于管理问题，您无法在实际项目中实践单元测试，我会选择在一些小型玩具项目上进行实践，只是为了强迫自己找到一种方法来编写可测试代码，即使没有单元测试

---

我自己的2美分。

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

• 换工作就行了。如果一家公司的经理给出了这样的答案，那么它无论如何都会失败，而且很快就会失败。趁现在还不太晚，赶紧出去

• 扭转指责的局面。每次在没有进行单元测试的情况下发布某些内容时，都要做出一个官方声明，说明它已经完成了，并且您不能保证它没有bug

• 写下您在任务上花费的时间，分离部署失败后的bug修复，并根据（潜在）编写单元测试的时间分配进行合计

---

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

例如： 投资：

• 实施测试所花费的时间 基础设施（无严重问题的产品） 单元测试可以在没有 测试特定的基础结构代码 这简化了特定产品的流程 测试模式、测试数据 创建/删除等）
• 花在编写实际测试上的时间
• 花在复习和学习上的时间 支持性测试
• 等等

利润：

• 没有任何虫子会在没有任何迹象的情况下再次出现
• 未通过单元测试，不发布主要功能
• 对于大多数bug，周期开发qa修复bug被减半：开发单元测试修复bug
• 等等

---

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

如果你发布的答案真的是你的经理所说的，那么你为白痴工作，也许一些硬数据可以左右他们。考虑到市场，退出不太可能是一种选择，玩办公室政治也不会让你有任何进展（或提高代码质量）

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

你必须给他们看。如果他们不能被说服，我就会开始寻找。

---

静静地；）

另外一个想法是对这个线程的其他优秀评论进行补充（其中许多我都投了赞成票）：确保您的管理层知道单元测试在这一点上是高度自动化的。我发现在屏幕上弹出NUnit，点击“全速运行”按钮，看到数十个绿灯亮起的测试在几秒钟内通过，这给我留下了深刻的印象。这样做一次，说“这验证了我所有的旧作品仍然是正确的，尽管我所有的新的变化”，你可能会赢得一些转化。在任何情况下，他们都会比其他人更信任你——用你看得见的质量证明。这只会对你的职业生涯有好处。

经典的回答是，你越早发现一个bug，修复它的成本就越低，我认为大多数管理者都会认同这一点

---

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

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

将单元测试应用于反复出现的bug-这是证明单元测试价值的最佳用例。当您的bug每隔一次构建就出现并重新出现时，单元测试将允许开发人员查看哪些更改导致了bug，并提前提醒他们修复已就绪。向管理层演示也很容易

将单元测试应用于常规bug-现在单元测试的有用性已经得到了明确的证明，长期内反复出现的几个bug消失的实例应该足以使