有人对正式单元测试的效用有衡量标准吗？我看到很多关注单元测试工具，我很好奇为什么？
我在 5 或 6 年前停止了正式的单元测试，生产力的净收益似乎相当高。我停止了单元测试，因为我注意到它从来没有捕捉到任何东西——更不用说任何有用的东西了。单元测试检测到的错误类型似乎可以通过每小时不喝超过 2 杯葡萄酒/啤酒（或每小时 2 杯）来预防。此外 - 单元测试似乎通过允许开发人员认为有一些保护措施来捕捉他们的错误而产生风险。
我进行测试以确保代码正常工作，但我不使用任何工具。我根据所做的更改进行测试。我对新代码的生产错误率大约为零。我对代码更改的错误率约为每季度 2-3 个错误。上述措施基于我开发/支持的 4 个生产应用程序。
我承认你作为人类和编码员的优越性。
然而，我只是个白痴，如果没有 Python 单元测试，我会迷路。
没有单元测试我无法重构，它需要太多的思考。
如果没有单元测试，我几乎无法编码，很难绝对确定我绝对理解每一个细微差别。
我进行单元测试是因为我是个白痴。由于您不会犯错误，因此您显然不需要进行单元测试。我向你们致敬。
编辑。对我来说，单元测试与指标或成本无关。我不需要任何随机的、受控的实验来向我展示价值。没有他们我无法工作。事实上，我拒绝在没有他们的情况下工作。同样，如果没有编译器、文本编辑器或源代码控制，我将无法工作。没有要求我不会工作；我拒绝在没有先做设计的情况下编程。
我不认为单元测试可以替代传统测试，而是作为确保代码正确性的额外步骤。我发现单元测试有用的一些特定领域是：
可能还有一些我已经忘记了:-P
PS：你怎么知道你没有制造错误？我不认为我会在我处理的代码中引入错误，但这肯定不会如此。恕我直言，认为您的代码没有错误是天真的。
（关于单元测试，如果你知道你的代码可能包含错误——我会说大多数代码都有——你不想使用所有可能的方法来捕获它们吗？）
这是一些关于单元测试的白皮书，可能会对您有所帮助：
但是，Martin Fowler说，支持单元测试和 TDD 的轶事证据是压倒性的，但你无法衡量生产力。
单元测试很好，因为您可以更改一个部分并知道它是否在其他地方修改了某些内容。有些人“爱上了”单元测试，应该让自己冷静下来。我相信单元测试，但试图隐藏一切的人与不进行单元测试的人一样危险。
我没有任何指标可以指出，但我认为受欢迎程度的上升是因为我们其他人的经历与你的相反。:)
这是一个线程，对 TDD 方法进行了一些 研究
通过单元测试，我可以修复生产代码中的错误并在发现错误的一小时内安装新版本，并且我可以确定新版本不会比我们以前的版本更差 - 因为测试告诉我。不过，它可能会更好。
他们给了我一个较低的水印，我的代码质量永远不会低于这个水印。它们使我能够跟踪更大的图景，并让测试发现我倾向于犯的小错误。它们也让我能够以一种非常轻松的方式发展。
自从我测试以来，我倾向于按时交付，我的代码质量提高了很多，结果通常按预期工作。此外，我的速度要快得多，因为我可以偷工减料，如果我没有进行测试，那将太危险而无法尝试。
也就是说，尽管我多年来一直在进行单元测试和 TDD，但我也没有任何确切的数字，也不知道任何来源。我对测试的热爱是基于纯粹的口口相传和个人经验。
我发现在添加新功能时单元测试可以帮助我。在这种情况下，我曾经担心我添加的内容会破坏应用程序的某个远程部分中的某些内容。但是通过适当的单元测试，我知道我在运行测试时是否破坏了某些东西。
这是关于单元测试效用的有趣讨论。
如果您不喜欢单元测试，您可能想要研究的另一个概念是按合同设计。 这基本上断言，如果满足某些输入条件，那么根据合同将有保证的输出。
我是一名开发经理。对于我的组织，设置和迁移到 nhibernate 需要一些设置成本并增加了我们的开发时间。一些开发人员喜欢它，有些人认为这是浪费时间。
错误率没有明显变化，但也许现在说还为时过早。
从我的角度来看，我认为它可以帮助那些不确定自己的工作的初级开发人员，但对于高级开发人员来说，这似乎会减慢他们的速度——保持更新是另一回事。我不确定我们是否会继续使用它，恢复到我们的旧方式（临时单元测试），或者让开发人员做出个人选择。
有几种工具可以通过单元测试来衡量代码覆盖率。它们与单元测试一起是必不可少的部分，以确保代码不仅经过测试，而且经过完整测试。
其他一切都只是纯粹的魔法；）
如果您想重构代码，根据定义，您需要某种方式来判断更改是否破坏了代码。缺乏神圣的洞察力，我发现单元测试是一个很好的工具，但是 ymmv。
我在一个巨大的单片服务器应用程序上使用 C++ 测试驱动开发 (TDD) 获得了很多收益。
当我在一个代码区域工作时，我首先确保在我更改或编写新代码之前测试覆盖了该区域。
在这个用例中，我在生产力方面取得了巨大的进步。
这意味着我能够非常快速地迭代代码区域，并且仅在需要时才进行全面测试。
除此之外，我还使用了集成测试，它需要更长的时间来构建和运行，但只执行我感兴趣的特定功能。
我对你所说的有些同情。我的经验是相似的，因为我的新错误很少被单元测试发现。如果有的话，在发现错误后修改单元测试以确保它不会再次出现。
单元测试对我有帮助的地方在于我的（Java）类的设计。我经常重构这些类以使它们可测试（例如删除单例），我认为这改进了整体设计。对我来说，这就是使用它们的充分理由。
根据我的经验，单元测试帮助我解决了以下问题：
然而，这与我有点相关，因为我对“一次管理多个东西”和“专注”真的很糟糕。因此，单元测试对我有用，并且多次节省了我的时间，在那里我引入了一个新功能，它打破了一些旧功能。
如果您不是这种情况，请不要使用它。如果您仍然拥有相同的结果、性能和质量，但存在相同数量的错误，那么这意味着您不需要单元测试。或者你需要修改你的单元测试方法。
PS根据你的错误率和你所说的你听起来像个天才（假设这些是中型或大型项目），所以我会说不要使用单元测试，看起来你做得很好。但是对于像我这样不是天才的世界其他人，我强烈推荐单元测试，因为它对我有用。
不知道关于你，但我刚刚检查了两个核心转储的两个修复程序，这些修复程序是由我的单元测试捕获的现有代码的更改创建的。而且我刚刚遇到了一个重大的生产问题，如果我对它的结果有更多的信任（我们的单元测试在功能方面比我想承认的要多一点），那么单元测试就会发现这个问题。
在我看来，使用流行的测试工具进行正式的单元测试很像美国的机场安检。
我认为人们对软件有不同的看法。在我看来，软件是一种赚钱的方式（希望通过增加收入或省钱）。我看过 TDD 的帖子，这是我认为最接近回答问题的科学方法，但该方法缺乏科学严谨性。指定的文章都没有基线或相当对比的替代方法。
我想，正式单元测试的拥护者将继续以他们的方式感到安全。我将继续将我的规格写在一张纸上，然后放入我的圣安东尼雕像脚下的碗中并祈祷。谁能说哪种方式更有效，但我的方式确实感觉很好……也许我会写一篇关于它的白皮书。
记住 70 年代和 80 年代的发型和衣服越来越受欢迎……这对我们这些生活在这几十年里的人来说并不是那么好。
正式的单元测试需要大量的工作和努力来维护。我猜想实际开发软件需要 20-50% 的时间。我要问的是，为每项开发工作增加 20-50% 开销的已知价格是值得关注和/或可证明的收益。
通过不进行正式的单元测试，您正在迫使开发人员考虑要测试的适当事物。开发人员对产品拥有更多所有权。
正式的单元测试听起来像蛇油汁……大家和他哥都说它好、好用、酷等等，但一直没有随机对照试验证明它实际上是省时省钱的。迄今为止的所有回应都是主观的证词。
我想知道的是，在引入单元测试之后，是否有软件经理能够展示出更高的生产力（甚至更高的质量）。
大声笑 - S.Lott 的诙谐咆哮是排名最高的回应......鉴于这个论坛是匿名的（无论如何对我来说），你的尊重不是我想要的。我认为自己勉强高于平庸。我曾与杰出的开发人员一起工作……这些人通常甚至不对他们的代码进行基本测试——他们只知道它会起作用。