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