unit-testing - 多少单元测试是一件好事？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




(似乎没有“相关问题”可以解决这个问题，所以这里是。)

我从事生产代码。有时，为用户不可见的任何事情争辩是很困难的。如果销售人员看不到它，这对他们来说就是外部成本，除非有充分的理由不这样做，否则他们会反对它。

多少单元测试是一件好事？如果您测试每个类、每个方法，您当前的版本将需要更长的时间，甚至可能更长。如果你什么都不测试， future 的维护将花费你更长的时间，可能会更长，因为错误修正和新功能会导致你没有预见到的问题，而单元测试会发现这些问题。

你如何找到一个健康、合理的平衡？

编辑:回答一些合理的人提出的问题......

销售人员不运行流程，但他们肯定有输入，并且在任何组中都应该有有限的输入。他们是支付账单的人。如果他们完全掌控一切，那显然是不合理的。

我敢肯定没有最佳答案，但我很好奇其他人认为什么是合理的。我期待两个极端(一切!什么都没有!)，以及中间的很多。

没有人可以选择他们的经理，如果一个糟糕的单元测试政策对于留在公司/项目的人来说是一个成败的决定......你的职业选择比我们大多数人都多， friend 。 :-)

第二次编辑:“正当”是其中的一个重要词。如果我想为单元测试安排/允许时间，并且不想偷偷溜进来，我将需要证明原因。对我来说，现在最重要的答案是“测试以前坏过的东西”，因为我总能证明 react 性策略是合理的。

关于如何证明某事积极主动的任何想法？

Answer 1

最小单元测试的两个建议将提供最大的“物有所值”:

首先分析您的应用程序以查找最常用的部分 - 确保这些部分经过单元测试。继续向外移动到不太常用的代码。

修复错误后，编写一个可以检测到它的单元测试。