单元测试的价值

Question

以下是一些典型的答案(按鸡毛蒜皮的顺序排列)，每当我提到单元测试和代码覆盖率作为开发周期的一个组成部分的重要性时，我都会从经理/老板那里得到。

1. 这是QA的工作，专注于特性和开发
2. 这个应用程序不是关键任务，如果有一些错误，它不是世界末日
3. “我们不能花时间在单元测试上”
4. “尽量别太花哨”

尽管有良好的意图做一个好的工作，在一天结束时，时间到了指责游戏，负担最终落在开发者身上。

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

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

更新:谢谢大家的许多有洞察力的建议。有几个答案，我希望我可以选择作为正确的答案。

Answer 1

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

例如:投资：

• 实现测试基础结构所花费的时间(如果没有特定于测试的基础结构代码来简化产品特定的测试模式、测试数据的创建/删除等，就不可能进行严重的产品单元测试)；
• 花时间写实际的测试；
• 审查和支持测试的时间；
• 等。

利润：

• 没有征兆，任何虫子都不会再出现；
• 在没有通过单元测试的情况下，不发布主要特性；
• 循环开发-qa-修复错误被削减一半，为大多数错误:开发单元测试修复错误；
• 等。

Answer 2

大多数经理都不会看到单元测试的优点，直到他们看到它在实际行动中才有意义，因此，根据经验，我的建议是采取ff步骤：

1. 将单元测试应用于反复出现的bug()--这是证明单元测试价值的最佳用例。当您有只会出现并重新出现每一个其他构建的bug时，单元测试将允许开发人员查看哪些更改导致了错误，除了预先提醒他们修复是正确的。这也很容易向管理层展示。
2. 将单元测试应用于常规的bug--随着单元测试的有效性现在已经清楚地证明了，从长期来看，反复出现的bug消失的几个实例应该足以鼓励每个人使用单元测试来评估所有的bug，以防止它们成为反复出现的bug。
3. 将单元测试应用于新功能--单元测试确保旧的bug不会重新出现，并确认它们是首先修复的，下一步是将其应用于新功能，以确保bug最小化。明确指出，不可能完全消除bug。
4. 应用全面的TDD -最后一步将是应用单元测试甚至在编码之前，作为一个设计工具，既有助于设计代码和减少bug。

当然，我并不是说这很容易--我上面说的是过于简单化，甚至我每天都在挣扎--很难说服每个人。

如果稍后您决定转到另一家公司，您可能希望显式地寻找一家实践TDD的公司。

Answer 3

人们听他们的钱包。显示通过早期捕获bug可以节省多少时间。把它转化为美元储蓄。