unit testing的价值
以下是每当我提出将unit testing和代码覆盖作为开发周期不可分割的一部分的重要性时，我从经理/老板那里得到的一些典型答案（按落纱顺序排列）
- “这是QA的工作，只关注function和开发”
- “应用程序不是关键任务，如果有一些错误，它不是世界末日”
- “我们不能花时间进行unit testing”
- “尽量不要过于花哨”
尽管做好了工作的最佳意图，但在责任游戏到来的那一天结束时，负担最终落在了开发者身上。
我经常看到生产中断的事情，其中一些可以通过运行unit testing来静态捕获这些错误来避免。
我只是想谈谈人们的经历是什么，以及解决这个问题的最佳方法是什么。
更新：感谢大家提供了许多富有洞察力的建议。 有几个答案，我希望我可以选择正确的答案。
将unit testing引入开发过程就像投资一样：你必须预先投入一些资金才能获得利润。 如果你坚持下去，管理层应该更加关注这个比喻：描述需要什么样的投资，然后制定利润计划。
例如：投资：
- 花在实施测试基础设施上的时间（如果没有特定于测试的基础设施代码，可以简化产品特定的测试模式，测试数据创建/删除等，则无法进行严格的产品unit testing）;
- 花在编写实际测试上的时间;
- 花在审查和支持测试上的时间;
- 等等
利润：
- 没有标志就没有错误重新出现;
- 没有unit testing通过，不会发布主要function;
- 循环开发-qa-fix错误减少了大部分错误：开发unit testing修复错误;
- 等等
大多数管理人员看不到unit testing的优势，直到他们在有意义的行动中看到它，所以根据经验，我的建议是采取ff步骤：
- 将unit testing应用于重复出现的错误 – 这是certificateunit testing价值的最佳用例。 如果您出现的错误只是出现并重新出现在其他每个版本中，那么unit testing将允许开发人员查看哪些更改导致了错误，除了事先提醒他们修复程序是有序的。 向管理层展示也很容易。
- 将unit testing应用于常规错误 – 现在已经清楚地展示了unit testing的有用性，长期消失的多个重复错误实例应该足以鼓励每个人使用unit testing来评估所有错误，以防止它们成为重复出现的错误。
- 将unit testing应用于新function – 通过unit testing确保旧错误不会重现，并确认它们首先被修复，下一步是将其应用于新function以确保最小化错误。 明确表示不可能完全消除错误。
- 应用完整的TDD – 最后一步是在编码之前应用unit testing，作为一种设计工具，既有助于设计代码，又可以最大限度地减少错误。
当然，我并不是说这很容易 – 我上面所说的是过于简单化，即使我每天都在努力 – 很难说服每个人。
如果您以后决定转到另一家公司，您可能希望明确寻找一家实施TDD的公司。
人们听他们的钱包。 通过尽早捕获错误来显示您可以节省多少时间。 将其转化为美元储蓄。
关于＃3，花时间进行unit testing很可能会缩短整体上市时间。 好文章 – http://blog.scottbellware.com/2008/12/does-test-driven-development-speed-up.html
对我来说，采用unit testing的最大好处是我可以改变我的编码行为，使其更易于测试，换句话说，以更松散的耦合方式。
如果由于管理问题你不能在你的真实项目中练习unit testing，我会选择练习一些小玩具项目，只是为了让自己找到一种方法来编写可测试的代码，即使没有unit testing。
我自己2美分。
如果unit testing，我假设你在这里谈论TDD，那对你来说很重要，你应该用你自己的时间来编写它们（假设你有时间）。 如果你这样做，请记录你实际花费多少时间来编写它们，以及它们在一两个发布周期到位后记录一些数据。
如果您发布的答案确实是您的经理所说的，那么您就会为白痴工作，也许一些硬数据可能会影响他们。 鉴于市场，戒烟不太可能是一种选择，而且办公室政治不会让你到处（或提高你的代码质量）。
在您的经理了解TDD不仅仅是为了防止错误或“测试”之前，他们永远不会得到它。 TDD是关于设计和整体代码质量。
你必须展示它们。 如果他们无法被说服那么我会开始寻找。 悄悄地;）
我的简短而不完整的建议是：
-
换工作吧。 管理层提供这种答案的公司无论如何都会失败。 在为时已晚之前退出。
-
扭转责备游戏。 每次发布某些内容时都会发布一份官方声明，而不进行已经完成的unit testing，并且您不能保证它没有错误。
-
记下你花在任务上的时间， 将失败的部署后的错误修复分开 ，并将其与编写unit testing的（潜在）时间分配相加。
你为什么不为你的代码编写unit testing？ 你知道是否有其他开发人员遇到同样的问题？ 可能他们也会按照你的例子编写unit testing。
我不认为问题是集成服务器的技术或成本。 问题在于管理层对unit testing的态度。 因此，与所有开发人员说服他们。
这个post中有很多提示（ Jon Limjap的答案 ），试一试！
不要以特定方式出售管理层; 这将是困难的，并不会真的会给你带来太大的收获。 您的管理链是否认可unit testing代码并不重要。
当然，unit testing代码有很多与之相关的好处，但不要依赖管理层的购买来编写测试。 当人们开始看到结果时，他们会涌向正确的事情。
另一个想法是添加到这个线程的其他优秀评论（其中许多我已经投票）：确保你的管理层知道unit testing在这一点上是非常高度自动化的。 我发现在屏幕上弹出NUnit非常令人印象深刻，点击“全部运行”按钮，看到几秒钟内传递了数十个绿灯测试。 这样做一次，说“这certificate尽管我所有的新变化，我所有的旧工作仍然是正确的”，你可能会赢得一些转换。 无论如何，他们会相信你 – 用你可见的质量certificate – 比他们信任别人更多。 这只会对你的事业有益。
那么经典的反应就是你越早捕获一个bug就越便宜，我认为大多数管理人员都可以解决这个问题。
正如马克所说的那样具体化是最好的方法来说服PHB这些东西是好的，因为他们习惯于听说话，可能不知道unit testing和其他测试之间的区别。
现在有一个资源可以提供帮助。 一个现代的用例列表，TDD的有形证据。
您是否需要说服您的老板或队友使用TDD？ 这不是一些理论吗？ 这不仅仅是inheritance人说的吗？
现在，您可以查看WeDoTDD.com ，这是TDD公司列表以及这些团队背后的故事。
这正是我创建这个网站的原因，为了解决围绕“TDDcertificate”和“TDD工作”以及“谁在做TDD”的争论。
通过阅读这些公司背后的故事和实践它的团队，您还可以在那里学到很多关于这个主题的知识。