是否有人对正式的单元测试的实用性有度量？

Question

是否有人对正式的单元测试的实用性有度量？ 我看到很多对单元测试工具的关注，我很好奇为什么？

我在5到6年前就停止了正式的单元测试，生产率的净收益似乎很高。 我停止了单元测试，因为我注意到它从来没有捕获任何东西-更不用说任何有用的东西了。 通过每小时不喝超过2杯葡萄酒/啤酒（或每小时不超过2个关节），似乎可以预防单元测试检测到的错误类型。 另外-单元测试似乎通过允许开发人员认为存在一些可以掩饰其错误的保护措施而带来了风险。

我进行测试以确保代码能够正常工作，但是我不使用任何工具。 我根据所做的更改进行测试。 新代码的生产错误率大约为零。 我对代码更改的错误率大约是每季度2-3个错误。 以上措施基于我开发/支持的4种生产应用程序。

Answer 1

我承认您是人类和编码者的优势。

但是，我只是个白痴，没有Python单元测试，我会迷路的。

没有单元测试，我无法重构，这需要太多的思考。

没有单元测试，我几乎无法编写代码，很难绝对确定我绝对理解每一个细微差别。

我是白痴，所以进行单元测试。 由于您不会犯错误，因此您显然不需要进行单元测试。 我向你们致敬。

---

编辑。 对我而言，单元测试与指标或成本无关。 我不需要任何随机的，受控的实验就可以显示出它的价值。 没有他们，我无法工作。 确实，我拒绝没有他们的工作。 同样，如果没有编译器，文本编辑器或源代码控件，我将无法工作。 没有要求，我不会工作； 我拒绝不先做设计就编程。

Answer 2

我不认为单元测试可以替代传统测试，而可以作为确保代码正确性的额外步骤。 我发现单元测试有用的一些特定领域是：

• 重构/更改现有代码时。 单元测试将验证至少那些情况仍然可以按预期进行。 测试次数越多，您就越有可能确定代码更改不会破坏现有代码。
• 提交错误报告时。 进行暴露一个错误的单元测试是演示该错误并知道何时修复该错误的好方法。
• 一种设计接口的方法。 您有一些测试代码可以用来检查接口。

我可能已经忘记了一些其他问题：-P

PS：您如何知道自己没有错误？ 我不认为我会在所处理的代码中引入错误，但事实并非如此。 恕我直言，认为您的代码没有错误是天真的。

（关于单元测试，如果您知道您的代码可能包含错误-我会说大多数代码都包含-您是否不想使用一切可能的方法来捕获它们？）

Answer 3

这是一些有关单元测试的白皮书，可能会对您有所帮助：

• 白皮书＃1
• 白皮书2
• 白皮书3

但是， 马丁·福勒 （ Martin Fowler）认为，支持单元测试和TDD的轶事证据是压倒性的，但您无法衡量生产率。

单元测试很好，因为您可以更改零件并知道它是否在其他地方进行了修改。 有些人“爱上了”单元测试，应该让自己平静下来。 我相信单元测试，但是那些试图隐瞒一切的人对于没有单元测试的人来说是危险的。

Answer 4

我没有任何指标要指出，但是我认为受欢迎程度的上升是因为我们其他人的经验与您相反。 :)

Answer 5

这是一个有关TDD方法的研究线索

是否有确凿的证据证明单元测试的投资回报率？

Answer 6

通过单元测试，我可以修复生产代码中的错误，并在发现错误的一小时内安装新版本，并且可以确定新版本不会比我们以前的版本差-因为测试可以告诉我。 不过可能会更好。

它们给了我较低的水印，低于此水印我的代码质量永远不会下降。 它们使我能够跟踪大局，并让测试发现我容易犯的小错误。 它们也使我以轻松的方式发展。

自测试以来，我倾向于按时交付，我的代码质量得到了很大改善，并且结果通常可以按预期工作。 此外，我的速度也快得多，因为我可以偷工减料，如果没有测试，尝试将非常危险。

就是说，尽管我多年来一直在进行单元测试和TDD，但我也没有任何硬性数字，也不知道任何消息来源。 我对测试的热爱是基于纯粹的口口相传和个人经验。

Answer 7

我发现添加新功能时，单元测试可以帮助我。 在这种情况下，我曾经担心添加的内容会破坏应用程序某些远程部分的内容。 但是通过适当的单元测试，我知道在运行测试的那一刻是否已经损坏了某些东西。

这是关于单元测试的实用性的有趣讨论。

如果您不喜欢单元测试，则可能要考虑的另一个概念是“ 按合同设计”。 它基本上断言，如果满足某些输入条件，则根据合同将有保证的输出。

Answer 8

我是开发经理。 对于我的组织而言，设置和迁移到Nhibernate涉及一些设置成本，并增加了我们的开发时间。 有些开发人员喜欢它，有些认为这是浪费时间。

错误率没有明显变化，但现在还为时过早。

从我的角度来看，我认为它可以帮助不确定其工作的初级开发人员，但是对于高级开发人员而言，它似乎使他们的速度变慢了-保持更新是一回事。 我不确定我们是否会继续使用它，恢复到以前的方式（临时单元测试），还是让开发人员做出个人选择。

Answer 9

有几种工具可用于测试单元测试的代码覆盖率。 它们与单元测试一起是必不可少的部分，以确保不仅对代码进行了测试，而且对它们进行了完整的测试。

其他一切都只是纯魔术;）

Answer 10

如果要重构代码，按照定义，您需要某种方法来判断更改是否破坏了代码。 缺乏神圣的见解，我发现单元测试是一个非常好的工具，但是非常好。

Answer 11

我特别在大型的单片服务器应用程序上使用带有C ++的测试驱动开发（TDD）获得了很多收益。

在处理代码区域时，在更改或编写新代码之前，我首先要确保该区域已被测试覆盖。

在这种用例中，我在生产率方面有巨大的收获。

• 建立并运行我的测试：10秒。
• 要构建，运行并手动测试整个服务器：最少5分钟。

这意味着我能够非常快速地迭代一段代码，并且仅在需要时才进行全面测试。

除此之外，我还利用了集成测试，该测试花费了较长的构建和运行时间，但仅使用了我感兴趣的特定功能。

Answer 12

我对你的意思表示同情。 我的经验相似，因为我的新错误很少被单元测试捕获。 如果有的话，在发现错误之后，将对单元测试进行修改，以确保它不会再次出现。

单元测试对我有帮助的地方是我的（Java）类的设计。 我经常重构类以使其可测试（例如删除单例），我认为这改善了总体设计。 对我来说，这足以使用它们。

Answer 13

以我的经验，单元测试帮助我完成了以下工作：

• 现在，我可以将所有精力放在正在编写的代码块/函数/类上，而不必担心其他任何事情，因为我知道如果我做一些愚蠢的操作或引起副作用，我的测试就会告诉我
• 我可以通过知道自己没有破坏东西来重构东西
• 我确定我的应用程序可以正常运行
• 在发布之前，我不会手动检查每一项功能以确认该应用程序仍能正常运行，
• 我确定我的应用程序一定程度上一直稳定

但是，这与我有点关系，因为我对“一次管理多个内容”和“集中精力”确实很不好。 因此，单元测试为我工作，实际上节省了我很多时间，在此我引入了一项新功能，但它破坏了一些旧功能。

如果不是这种情况，那就不要使用它。 如果您仍然具有相同的结果，性能和质量以及相同数量的错误，那么这意味着您不需要单元测试。 或者您需要修改单元测试方法。

PS根据您的错误率以及您所说的听起来还是个天才（假设这些是中型或大型项目），因此我要说不要使用单元测试，看来您做得不错。 但是对于像我这样的天才以外的世界其他地区，我强烈推荐单元测试，因为它对我有用。

Answer 14

Dunno关于您，但是我刚刚检查了两个修复程序，以解决由于单元测试捕获的现有代码更改而创建的两个核心转储。 如果我对结果有更多的信任，我只是遇到了一个重大的生产问题，而单元测试可能会抓住这个问题（我们的单元测试在功能方面比我想承认的要多得多）。

Answer 15

在我看来，使用流行的测试工具进行的正式单元测试与美国机场安全非常相似。

• 它提供了安全的错觉
• 它使人们“感觉”良好
• 这非常不方便（如果您弄错了肤色，则非常不便）
• 如果您批评它，人们会生气地向您挥动拳头。
• 当他们的过程失败时，这些相同的人将被迷惑，他们将跳上下一辆旅行车...

我认为人们对软件有不同的看法。 在我看来，软件是一种赚钱的手段（希望通过增加收入或节省金钱）。 我看过有关TDD的帖子，这是我认为是最科学的回答问题的方法，但该方法缺乏科学严谨性。 指定的文章都没有基准或相当对比的替代方法。

我想，正式单元测试的拥护者将继续以自己的方式感到安全。 我将继续将规格写在纸片上，放在我的圣安东尼雕像脚下的碗里，并祈祷。 谁说哪种方法更有效，但是我的方法肯定不错……也许我会写一份白皮书。

Answer 16

请记住，70年代和80年代的理发和衣服的流行度上升……对于那些生活在那几十年中的我们来说，这并不是一件好事。

正式的单元测试需要大量的工作和维护工作。 我猜想，实际开发软件需要20-50％的时间。 我要问的是每项开发工作都要增加20-50％开销的已知价格，这是值得注意的和/或可证明的。

通过不进行正式的单元测试，您将迫使开发人员考虑进行适当的测试。 开发人员获得了产品的更多所有权。

正式的单元测试听起来像蛇油汁……每个人和他的兄弟都说它很好，有用，很酷，等等，但是还没有一项随机对照试验来证明它确实节省了时间或金钱。 到目前为止，所有答复均为主观证词。

我想知道的是，在引入单元测试后，是否有一个软件经理可以证明更高的生产率（甚至更高的质量）。

大声笑-S.Lott的恶作剧是获得最高评价的响应...鉴于该论坛是匿名的（无论如何对我来说），您的尊敬不是我想要的。 我认为自己勉强能做到平庸。 我曾与杰出的开发人员一起工作过……这些家伙通常甚至不对其代码进行基本测试-他们只知道它会工作。