多少单元测试是一件好事？ [关闭]答案

【问题标题】：How much unit testing is a good thing? [closed]多少单元测试是一件好事？ [关闭]
【发布时间】：2010-12-03 09:08:35
【问题描述】：

（似乎没有“相关问题”可以解决这个问题，所以就这样吧。）

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

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

您如何找到健康、合理的平衡？

编辑：回答一些理性的人提出的问题...

销售人员没有运行该流程，但他们肯定有意见，并且应该在任何组中都有有限的意见。他们是支付账单的人。如果他们完全掌控一切，那显然是不合理的。
我确定没有最佳答案，但我很好奇其他人认为什么是合理的。我期待两个极端（一切！什么都没有！），中间还有很多。
没有人可以选择他们的经理，如果一个糟糕的单元测试政策对于留在公司/项目的人来说是一个决定成败的决定......你有很多 em> 比我们大多数人有更多的职业选择，朋友。 :-)

第二次编辑：“合理”是其中的一个重要词。如果我想为单元测试预算/允许时间，并且不想偷偷溜进去，我需要证明原因。对我来说，现在最重要的答案是“测试以前破坏过的东西”，因为我总能证明反应性政策是合理的。

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

【问题讨论】：

为什么“销售”在您的软件开发过程中运行？您需要一位真正了解软件开发的开发主管/经理。
@Nate - Jon Skeet 可以灵活地选择他喜欢的高级管理人员。有些人就没那么幸运了:)
这是一个有争议的话题。确实没有最佳答案，因为有些情况下测试是有益的，有些情况是浪费时间的。我们产生可接受的答案的唯一方法取决于您描述您的个人情况的程度。
@DVK，即便如此，在某种程度上，销售人员并没有坐在你的肩膀上检查你的算法和监控你的构建脚本，同样他们也不会检查你是否正在编写单元测试，只要你有生产力。但是，如果您没有像样的经理，您将无法让团队这样做。
在Podcast #41 of StackOverflow Jeff 和 Joel 与 Bob Martin 叔叔讨论 TDD 覆盖。是一个很好的建议。阅读the transcript 或listen the podcast。我认为这对所有对此问题感兴趣的人都非常有用。

标签： unit-testing testing junit automated-tests

【解决方案1】：

关于最小化单元测试的两个建议，这将提供最大的“物有所值”：

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

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

【讨论】：

我实际上可能会推动这个；当我们发现错误时，不仅要花时间修复它，还要测试它，以免它再次成为错误。这似乎很容易争论；它可能是被动的而不是主动的，但这是一个很好的开始。

【解决方案2】：

我认为这是一个谬误：

如果你测试每一个类，每一个方法，您当前的版本需要更长的时间，可能更长。

测试 - 尤其是测试优先 - 改善了我们的流程，让我们保持在区域内，实际上加快了我们的速度。我可以更快地完成工作，因为我进行了测试。测试失败会拖慢我们的速度。

我不测试 getter 和 setter；我认为那毫无意义——尤其是因为它们是自动生成的。但几乎所有其他内容 - 这是我的做法和建议。

【讨论】：

+1。这是一个令人愤怒的谬论，具有太多的吸引力。
完全同意。虽然编写测试可能会减慢初始代码的速度（例如前几百行），但我发现它可以加快一切速度。

【解决方案3】：

开始为最有问题的区域创建单元测试（即，经常中断并导致销售团队和开发人员之间进行大量沟通的代码部分）。这将立即对销售团队和其他人员产生明显的影响。

然后，一旦您具有可信度并且他们看到了价值，就开始添加问题较少的区域，直到您开始注意到投资回报率不再存在。

当然，全面覆盖在理论上很好，但在实践中通常没有必要。更不用说太贵了。

【讨论】：

【解决方案4】：

给我的建议是这样的：

按您的想法尝试；一段时间后，评估一下自己：
如果测试花费的时间比您认为合理的要多，而且您的投资回报太少，请减少测试。
如果您的产品经过充分测试而您浪费了时间，请进行更多测试。
根据需要循环。

另一种算法：:-)

有些测试确实简单且非常有用。始终以高优先级执行此操作。
有些测试确实很难设置，而且很少有用（例如，它可能会被您的流程中经常发生的人工测试所复制）。不要再这样做了，这会浪费你的时间。
在两者之间，尝试找到一个平衡点，这可能会随着时间的推移而变化，具体取决于您的项目阶段......

更新评论，关于证明一些测试的有用性（你坚信的那些）：

我经常告诉我的年轻同事，我们这些技术人员（开发人员等）缺乏与管理层的沟通。正如您所说，对于管理而言，未列出的成本不存在，因此它们避免它们不能用来证明另一个成本是合理的。我曾经也为此感到沮丧。但仔细想想，这就是他们工作的本质。如果他们在没有正当理由的情况下接受不必要的成本，他们将是糟糕的管理者！

这并不是说他们否定我们这些活动是正确的，我们知道这些活动是有用的。但我们首先必须明确成本。更重要的是，如果我们以适当的方式报告成本，管理层将不得不做出我们想要的决定（否则他们将是糟糕的管理者；请注意，该决定可能仍被优先考虑......）。所以我建议跟踪成本，这样它们就不会再被隐藏了：

在您跟踪所花费时间的地方，单独注明来自未经测试的代码的成本（如果工具中没有，请将其添加为注释）
如果工具没有，将这些成本汇总到专门的报告中，这样每周，您的经理就会看到您有 X% 的时间花在了上面
每次评估负载时，分别评估几个选项，无论是否使用自动化测试，显示手动测试或自动化测试所花费的时间大致相同（如果您将自己限制在最有用的测试，如前所述），而后者是针对回归的资产。
将错误链接到原始代码。如果链接不在您的流程中，请找到一种方法来连接它们：您需要证明该错误来自没有自动测试。
同时收集这些链接的报告。

要真正影响经理，您可以每周向他们发送一份最新的电子表格（但要包含整个历史记录，而不仅仅是一周）。 SpreadSheet 提供的图形可以立即理解，并让不信的经理得到原始数字...

【讨论】：

我遇到的问题是向外部团体证明这一点；凭耳朵玩很好，但我需要证明我的决定是正确的，而且衡量“投资回报率”是困难，因为我没有我没有做出的选择的结果。

【解决方案5】：

“成本”在开发过程中支付，当它更具成本效益时，在持续维护期间实现回报，此时修复错误更加困难和昂贵。

我通常总是对以下方法进行单元测试：

读/写数据存储，
执行业务逻辑，并且
验证输入

然后，对于更复杂的方法，我将对它们进行单元测试。对于像 getter/setter 这样简单的东西，或者简单的数学东西，我不测试。

在维护期间，大多数合法的错误报告都会进行单元测试，以确保特定错误不会再次发生。

【讨论】：

【解决方案6】：

我始终相信不要极端。特别是在时间和精力有限的情况下。你不能全部测试。

并非每个方法/函数都需要单元测试。以下可能不需要。 (1) 显然并不复杂，例如 get/set、小条件或循环。 (2) 将被具有单元测试的其他方法调用的方法。

有了这两个标准，我认为你可以削减很多。

只是一个想法。

【讨论】：

你总是相信不要太极端？哦，具有讽刺意味！

【解决方案7】：

IMO，如果有足够的东西可以给继承代码的人一个想法，以便他们可以开始进行更改，无论是修复错误还是进行增强，而无需花费数天时间阅读代码来获得它，那是我的建议。

因此，不要将所有东西都测试到死，但要涵盖一些常见情况和一些边缘情况，看看如果事情没有按照最初的规定进行会发生什么。

【讨论】：

【解决方案8】：

进行足够的测试，这样您就可以放心，错误的重构会被测试捕获。通常，它足以测试逻辑和管道/接线代码。如果您有本质上是 getter/setter 的代码，为什么要测试它们？

关于销售人员认为不需要测试的意见 - 好吧，如果他们知道这么多，为什么不进行该死的编码？

【讨论】：

我对销售人员也说过同样的话，但老实说，除非我提出一些理由，否则他们不会“明白”。也就是说，在我工作过的大多数组织中，销售具有短期激励作用。开发人员通常具有长期激励作用；没有现金奖励可以更快地发布，但从长远来看，如果你做得更有效率，就必须少努力工作。

【解决方案9】：

自动化单元测试带来了很多好处。我们已经在几个项目中使用了它。如果有人破坏了构建，每个人都会立即知道是谁做的，他们会修复它。它还内置在更高版本的 Visual Studio 中。看看

测试驱动开发

它应该可以为您节省大量时间，并且不会产生大量开销。希望这可以帮助！如果有，请标记。

【讨论】：

我们是 Java，每小时使用 Hudson 从版本控制中提取代码，运行构建并在构建上进行测试，如果有任何问题，请给我们发送电子邮件。这是一个很棒的补充。

【解决方案10】：

对于单元测试，我的公司采用了相当好的策略：我们有一个分层的应用程序（数据层、服务层/业务对象、表示层）。

我们的服务层是与数据库交互的唯一方式（通过数据层中的方法）。

我们的目标是为服务层中的每个方法至少进行一个基本的单元测试。

这对我们来说效果很好 - 我们并不总是彻底检查每个代码路径（尤其是在复杂方法中），但每个方法都验证了其最常见的代码路径。

我们的对象没有经过单元测试，除非是通过服务层测试。它们也往往是“哑”对象——除了必需的方法（例如 Equals() 和 GetHastCode()）之外，大多数没有方法。

【讨论】：

表示层有什么测试吗？
手册。不过，我们对每个修复都进行了相当严格的冒烟测试。

【解决方案11】：

开发人员测试的目的是加快开发具有可接受质量水平的完整软件。

这导致了两个警告：

完全有可能做错了，所以它实际上会减慢你的速度。因此，如果您发现它会减慢您的速度，则很可能是您做错了。
您对“可接受的质量”的定义可能与营销的定义不同。最终，他们是对的，或者至少拥有最终决定权。

有效的软件是一个专门的利基市场，相当于由专业昂贵材料制成的高端工程硬件。如果您不在该市场之外，那么客户不会期望您的软件能够可靠地工作，而不是期望他们的衬衫能挡住子弹。

【讨论】：

【解决方案12】：

多少单元测试是一件好事：

单元测试不是静态的，一旦你完成并且你的工作完成了，它会在产品的整个生命周期中持续下去，直到你不会停止对产品的进一步开发

基本上每次都应该进行单元测试： 1）你做了一个修复

2) 新版本

3) 或者你发现了一个新问题

我没有提到开发期，因为在此期间您的单元级测试正在发展。

这里的基本内容不是数量（多少），而是单元测试的覆盖率

例如：对于你的应用程序，你喜欢一个特定的函数 X，你做一个
修复 X，如果没有触及其他模块，您可以进行单元测试
适用于模块 X ，现在这就是 X 的单元测试量
封面

所以你的单元测试必须检查：

1) 各接口

2) 所有输入/输出操作

3) 逻辑检查

4) 应用特定结果

【讨论】：

【解决方案13】：

我建议拿起这本书The Art of Unit Testing。第 8 章介绍了将单元测试集成到您的组织中。有一张很棒的表格（第 232 页）显示了两个团队试验的结果（一个使用测试，一个不使用测试）；测试团队将整个发布时间（包括集成、测试和错误修复）缩短了两天，并且在生产中发现了 1/6 的错误。第 9 章讨论了测试可行性分析，以便利用遗留代码获得最大的收益。

【讨论】：

如果仅用于经验数据，那似乎物有所值。谢谢！

【解决方案14】：

虽然有可能过度测试（收益递减点），但很难做到。测试（特别是在流程的早期测试）可以节省时间。缺陷在产品中停留的时间越长，修复的成本就越高。

经常进行早期测试，并尽可能全面地测试！

【讨论】：

【解决方案15】：

虽然单元测试很有用，但您绝对应该为每个版本制定系统测试计划 - 这应该包括测试应用程序的正常用例（用于回归）以及更深入地开发的特定功能。

自动化系统测试对于避免回归非常重要 - 单元测试都可以通过，您的应用仍将是一坨屎。

但是，如果您不能对所有用例进行自动化系统测试（大多数应用程序都有复杂的用例，尤其是在与 3rd 方系统和用户界面交互的情况下），那么您可以运行手动系统测试。

用户界面产生了主要问题 - 大多数其他事情都可以相对容易地自动化。有很多工具可以自动测试用户界面，但众所周知，它们很脆弱，即在每个版本中，都需要调整自动测试才能通过（假设没有新错误）。

【讨论】：