logo标签列表

单元测试的价值

c#.netunit-testing
11
以下是我向经理/老板提出单元测试和代码覆盖率作为开发周期不可或缺部分的重要性时，通常得到的一些典型答案（按陈词滥调程度升序排列）：
  1. "这是QA的工作，只需专注于功能和开发"
  2. "应用程序并非关键任务，如果有一些错误也不是世界末日"
  3. "我们不能浪费时间在单元测试上"
  4. "尽量不要太花哨"
尽管开发人员怀着最好的意图做好工作，但当责任最终落在开发人员身上时，往往会出现问题。
我经常看到在生产环境中出现故障，其中一些故障本可以通过运行单元测试来静态捕获并避免。
我只是想开展对话，看看人们的经验是什么，以及解决这个问题的最佳方法是什么。
更新：感谢大家提供了许多有见地的建议。有几个答案我希望能选为正确答案。
这确实是一个非常好的问题。实际上，这是Stack Overflow上最好的问题之一。 - TobiMcNamobi
可能是 单元测试是否值得投入精力？ 的重复问题。 - nawfal
看看我的回答，你可能需要改变最佳答案了 :). 实际的文档证据，而不是传闻。 - PositiveGuy
12个回答
10

将单元测试引入开发流程就像投资一样：您必须先花一些时间成本才能获得以后的利润。如果您坚持这个比喻，管理层应该更加关注它：描述所需的投资，然后制定获利计划。

例如：

  • 实施测试基础设施所需的时间（没有严谨的产品单元测试可能性，除非有针对产品的测试特定基础设施代码来简化特定于产品的测试模式、测试数据的创建/删除等工作）;
  • 编写实际测试所需的时间;
  • 审核和支持测试所需的时间;
  • 等等。

利润：

  • 没有 bug 会在没有预兆的情况下再次出现;
  • 没有通过单元测试的主要功能被发布;
  • 对于大多数 bug 来说，开发-质量保障-修复 bug 的循环缩短了一半：开发-单元测试-修复 bug;
  • 等等。
8
大多数经理在看到单元测试实际发挥作用并具有意义之前不会看到其优点，基于经验，我的建议是采取以下几个步骤：
  1. 将单元测试应用于反复出现的错误 - 这是证明单元测试价值的最佳用例。当您遇到每次构建时都会出现的错误时，单元测试可以让开发人员看到哪些更改导致了这些错误，并提前警告他们需要修复。这也很容易向管理层进行演示。
  2. 将单元测试应用于常规错误 - 现在已经清楚地证明了单元测试的用处，几个反复出现的错误在长期内消失应足以鼓励每个人使用单元测试来评估所有错误，以防止它们变成反复出现的错误。
  3. 将单元测试应用于新功能 - 在单元测试确保旧错误不会再次出现并确认它们首先被修复后，下一步将是将其应用于新功能，以确保错误将被最小化。请明确指出，完全消除错误是不可能的。
  4. 应用完整的TDD - 最后一步将是在编码之前甚至应用单元测试作为设计工具，既有助于设计代码，又有助于最小化错误。

当然，我并不是说这很容易 - 我上面所说的是一种过度简化了的表述，即使我每天也在挣扎鼓动所有人。

如果将来您决定转到另一家公司，您可能希望明确寻找实践TDD的公司。

7

人们会听从他们的钱包。展示你可以通过及早捕捉漏洞而节省多少时间。将其转化为节省的美元金额。

注：本文中不保留空格和换行符。

1
+1：无论如何都要进行单元测试。不要浪费时间去辩解或解释。只需做好它，实现更好、更经济的开发。 - S.Lott
6
5

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

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

这是我的个人看法。

这是一个很好的观点。我在自己编写的代码上进行单元测试，效果非常好。对我个人来说，它帮助我打破依赖关系，并确保我的代码设计具有灵活性和可扩展性。如果没有这个工具，某些方面会让我感到无能为力。 - Am I Crazy
3
如果你在谈论TDD，我假设你正在进行单元测试，那么这对你很重要，你应该利用自己的时间来编写它们（假设你有时间）。如果你这样做了，请记录一下你实际花费在编写它们上的时间，并在它们已经存在一个或两个发布周期后向你的经理提供一些数据。
如果你的经理真的是这么说的，那么你就是在为白痴工作，也许一些硬数据可以改变他们的想法。考虑到市场，辞职不太可能是一个选项，玩办公室政治也不会有什么好处（或者提高你代码的质量）。
除非你的经理明白TDD不仅仅是防止错误或“测试”，否则他们永远不会明白。TDD关乎设计和整体代码质量。
你必须向他们展示。如果他们无法被说服，那么我会开始寻找。悄悄地 ;)
+1 - 我不确定他是否真的在谈论引入TDD。但是，我很高兴你这样做了。 - Mark Brittingham
马克是正确的。我并没有特指测试驱动开发（TDD）。只是单元测试你的代码的想法。 - Am I Crazy
2

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

  • 换工作。一个管理层会给出这种回答的公司注定会失败，并且很快就会倒闭。在为时已晚之前离开。

  • 反转责任游戏。每次发布没有单元测试的东西时，发表一份官方声明，说明已经这样做了，并且您不能保证它没有错误。

  • 记录您在任务上花费的时间，将修复失败部署后的漏洞与其他任务分开，并将其总计与（潜在的）编写单元测试的时间分配进行比较。

1
不仅仅是在换工作的时候点个赞，还要确保你的管理层和（以前的）同事知道你为什么这样做。不要“支持”愚蠢的经理。 - John Saunders
2
为什么你不为你的代码编写单元测试呢？你知道是否有其他开发人员遇到了同样的问题吗？可能他们会效仿你的做法，也开始编写单元测试。
我认为问题并不在于技术或集成服务器的成本。问题在于管理层对单元测试的态度。所以要说服所有的开发人员去做单元测试，并让管理层接受这个观点。
这个线程中有很多提示（Jon Limjap's answer），可以试试！
2
不要向管理层推销某种方法，这只会让事情变得更加困难，而且并不能为你带来太多好处。无论你的管理层是否欣赏单元测试代码都不重要。
当然，对代码进行单元测试有很多好处，但不要依赖管理层的认可来编写测试。当人们开始看到结果时，他们会向着正确的方向聚拢。
1

在这个主题的其他出色评论中，还有一个想法要补充（其中许多我已经点赞）：确保您的管理层知道单元测试目前已经高度自动化。我发现将 NUnit 弹出屏幕，点击“运行全部”按钮并在几秒钟内通过数十个绿色测试非常令人印象深刻。只需这样做一次，说“这验证了尽管进行了许多新更改，但所有旧工作仍然是正确的”，您可能会赢得一些信徒。无论如何，他们会比其他人更信任您 - 因为您可见的质量证明 - 这对您的职业生涯只有好处。

我确实尝试过这个方法，在一个实例中使用单元测试来查找性能问题并修复它们，如果使用传统的开发技术，这将是困难的甚至不可能。在很大程度上，这是工作文化的问题。匆忙拼凑一些东西，然后转向下一件事。实时修复故障！ - Am I Crazy
哇，那真的很遗憾。如果你决定在其他地方寻找更好的工作，祝你好运！ - Mark Brittingham
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接