单元测试有什么意义？

Question

我最近加入了一个大量使用单元测试的团队.没有人可以向我解释为什么这种形式的测试如此重要,但他们将其视为法律.

我知道自动化测试的想法是为了防止回归,但我不认为这首先是一个问题.模块化,面向对象,简洁的代码,评论良好,没有回归问题.如果你是第一次正确构建它,并设计出将来发生的不可避免的功能增加,你将永远不需要测试.

而且,这不是优雅的错误处理和日志记录应该完成的吗？当你可以确保所有外部依赖项首先仔细检查它们的可用性时,为什么要花几周时间来断言断言语句和单元测试？

我是否傲慢地得出结论,单元测试是"坏"代码库的拐杖,这些代码库有缺陷且构建不良？

这是一个严重的问题.我在任何地方都找不到任何好的答案,如果我质疑自动化测试的目的,我问的每个人似乎都认为我是一个巨魔.

编辑:谢谢你的答案,我想我现在明白了.我看到有几个人投票删除,但我要感谢那些回答的人; 它真的有帮助!

Answer 1

没有人是完美的 - 你最终会犯错误.单元测试旨在捕获并查明错误的位置,以便:

• 增加对您编写的代码正确性的信心
• 增加对重构正确性的信心
• 跟踪在测试阶段引入错误的地方要简单得多

错误处理和日志记录仅在触发错误时有用; 单元测试是在测试而不是生产中触发错误的原因.

考虑以下...

您有一个包含3个不同部分的软件,每个部分都有2个不同的选项.

     A      C      E
    / \    / \    / \
in-<   >--<   >--<   >-out
    \ /    \ /    \ /
     B      D      F

你可以通过手动输入输入和检查输出来测试这一点 - 首先你要输入一些触发A,C,E的输入; 然后你会放入一些A,C,F等等,直到你通过B,D,F覆盖所有内容.

但请记住,B,D和F每个都有自己独立的参数和流量需要测试 - 我们会说每个参数和流量可能有10个.因此,至少10*10*10 = 1000需要检查不同的输入,仅适用于A,C,E情况.通过这6个组件有8种不同的可能流量,因此您需要检查8000种不同的输入组合,以确保您能够获得所有不同的输入.

另一方面,你可以进行单元测试.如果您清楚地定义每个组件的单元边界,那么您可以为A编写10个单元测试,为B编写10个单元测试,依此类推,测试这些边界.这为组件提供了总共60个单元测试,以及少量(例如每个流量为5个,因此为40个)集成测试,确保所有组件都正确连接在一起.总共有100个测试可以有效地实现相同的功能覆盖.

通过使用单元测试,您可以将获得相同数量的覆盖所需的测试量减少大约80倍!这是一个相对简单的系统.现在考虑更复杂的软件,其中组件的数量几乎肯定大于6,并且这些组件处理的可能情况的数量几乎肯定大于10.您从单元测试而不仅仅是集成测试中获得的节省不断增加.

Answer 2

简短的回答:是的,你是傲慢的.;)

假设你真的是完美的,你的代码不仅在你编写它时是正确和完美的,而且它还考虑了将来的所有要求.

现在....你怎么知道你的代码是完美和正确的？你需要测试它.如果没有经过测试,你就不能相信它有效.

这不仅仅是关于回归(因为这意味着代码曾经工作.如果它从未起作用怎么办？当它首次编写时它是错误的)

我知道自动化测试的想法是防止回归,但我不知道这首先是一个问题.模块化,面向对象,简洁的代码,评论良好,没有回归问题.

谁告诉你的？那个人应该被鞭打.面向对象的代码与其他任何代码一样容易出错.没有什么神奇之处,它不是银弹.在一天结束时,无论何时更改一段代码,都有可能在某个地方破坏某些东西.根据相关代码的不同,机会可能更大或更小,但无论代码有多好,您都无法确定除非进行测试,否则不会引入回归.

如果你是第一次正确构建它,并设计出将来发生的不可避免的功能增加,你将永远不需要测试.

不过,你是如何在第一次正确构建它的？正如我上面所说,为此,您需要进行测试,以向您展示代码的工作原理.但更重要的是,您如何"设计"将来会添加的功能？你甚至都不知道它们是什么.

而且,这不是优雅的错误处理和日志记录应该完成的吗？当你可以确保所有外部依赖项首先仔细检查它们的可用性时,为什么要花几周时间来断言断言语句和单元测试？

一点都不.

您的代码当然应该处理错误条件,它应该记录您需要记录的内容.

但是你仍然需要知道它能正确地做到这一切.而且您需要知道它也能正确处理非错误情况!很高兴知道"如果SQL服务器不可用,我们会向用户显示一条很好的错误消息并退出".但如果有什么是可用？那你的申请是否有效？

对于任何重要的应用程序,有很多事情可能会出错.有很多功能,很多代码和许多不同的执行路径.

试图手动测试它永远不会运用所有这些代码路径.它永远不会在每个环境中测试每个功能的每个方面.即使它确实如此,它只是告诉你"代码今天工作".明天会工作吗？你怎么知道的？当然,你的直觉可能会告诉你"我从那以后犯下的代码没有破坏任何东西",但你怎么知道呢？你需要再次测试它.然后再次.然后再次.

你问单元测试是否是错误代码库的拐杖.他们是相反的.他们是检查,医生访问,防止代码库变坏.他们不只是告诉你你的代码是否有效,但是当它运行时,更重要的是,当它停止工作时.你不认为你会引入任何回归吗？你有多确定？你能负担得起吗？

Answer 3

当您第一次开始编写代码时,它看起来很简单,并且不需要自动化测试.

但随着时间的推移,您的代码会增长,需求会发生变化,团队会发生变化.对自动化测试的需求也将增长.如果没有自动化测试,开发人员将害怕重构代码 - 特别是如果他们不是编写代码的人.即使使用精心设计的代码添加新功能也可能破坏现有功能.但代码并不总是经过精心设计.在实践中,您可能需要妥协.由于各种原因,您的某些代码将不像您想要的那样干净和可维护.当您意识到需要自动化测试时,可能无法添加它们,因为您的某些类可能难以测试.要添加第一个自动化测试,您可能必须首先重写或重构大量代码.

如果您从一开始就进行自动化测试,这将确保您将代码设计为可自动测试.