单元测试值得吗?[已关闭]

我们办公室每天都有这样的交流:

“伙计,我只是喜欢单元测试,我刚刚能够对某些东西的工作方式进行一系列更改,然后能够通过再次运行测试来确认我没有破坏任何东西……”

细节每天都在变化,但情绪却没有变化。单元测试和测试驱动开发(TDD)有很多隐藏的、个人的好处,也有明显的好处,只有在别人自己做之前,你才能真正向他们解释。

但是,忽略这一点,这是我的尝试!

1. 单元测试允许您快速对代码进行重大更改。你知道它现在可以工作了,因为你已经运行了测试,当你做出需要做出的更改时,你需要让测试重新工作。这样可以节省数小时。

2. TDD可以帮助您了解何时停止编码。你的测试让你相信,你现在已经做得足够了,可以停止调整,继续下一件事。

3. 测试和代码协同工作以获得更好的代码。你的代码可能不好/有漏洞。你的测试可能很糟糕。在TDD中,您希望 二者都 坏[卑鄙]。通常,这是一个需要修复的测试,但这仍然是一个好结果。

4. TDD有助于对便秘进行编码。当面临一项艰巨的工作时,编写测试会让你迅速行动起来。

5. 单元测试有助于你真正理解你正在处理的代码的设计。你不是为了做某事而编写代码,而是从概述你对代码的所有条件以及你期望从中得到什么输出开始。

6. 单元测试会给你即时的视觉反馈,我们都喜欢完成测试后那些绿灯的感觉。这很令人满意。在中断后,你也更容易从中断的地方重新开始,因为你可以看到你到了哪里——下一个需要修复的红灯。

7. 与流行的观点相反,单元测试并不意味着编写两倍多的代码,或者编码速度较慢。一旦掌握了窍门,它就比没有测试的编码更快、更健壮。测试代码本身通常相对琐碎,不会给你所做的事情增加很大的开销。只有当你这样做的时候,你才会相信:)

8. 我想是Fowler说的:“频繁运行的不完美测试比从不编写的完美测试要好得多”。我认为这是允许我在我认为最有用的地方编写测试,即使我的其余代码覆盖范围非常不完整。

9. 好的单元测试可以帮助记录和定义某件事应该做什么

10. 单元测试有助于代码重用。迁移两个代码 和 你的测试到你的新项目。调整代码,直到测试再次运行。

我参与的很多工作都没有很好地进行单元测试(网络应用程序用户交互等),但即便如此,我们在这家商店里都受到了测试感染,当我们的测试被束缚时,我们最开心。我对这种方法的推荐再高也不为过。

单元测试很像去健身房。 你知道这对你有好处,所有的论点都有道理,所以你开始锻炼。最初有一次高峰,这很好,但几天后你开始怀疑这是否值得。你一天中要花一个小时换衣服,骑着仓鼠轮子跑步,你不确定自己除了腿和胳膊酸痛之外真的有什么收获。

然后,也许一两周后,就在疼痛消失的时候,一个大的最后期限开始临近。你需要把醒着的每一个小时都花在努力完成“有用”的工作上,这样你就可以省去一些无关的事情,比如去健身房。你改掉了这个习惯,等到大截止日期结束时,你又回到了原点。如果你设法回到健身房,你会感觉和第一次去时一样疼痛。

你读一些书,看看你是否做错了什么。你开始对所有健康快乐的人赞美锻炼的优点感到有点不合理的怨恨。你意识到你们没有太多共同点。他们不必开车15分钟就可以去健身房;他们的大楼里有一个。他们不必与任何人争论锻炼的好处;这只是每个人都会做并接受的重要事情。当最后期限临近时,他们不会被告知锻炼是不必要的,就像你的老板会要求你停止进食一样。

所以,为了回答你的问题,单元测试通常是值得的,但所需的工作量并不是每个人都一样。 如果你在一家没有 事实上 值代码质量。(很多管理者会赞美单元测试,但这并不意味着他们会在重要的时候坚持它。)

如果你试图将单元测试引入你的工作中,但没有看到你所期望的所有阳光和彩虹,不要责怪自己。你可能需要找到一份新的工作来真正让单元测试为你工作。

说服的最佳方式。。。找到一个bug,为它编写一个单元测试,修复这个bug。

这个特定的错误不太可能再次出现,你可以通过测试来证明它。

如果你做得够多,别人会很快接受的。

walkingwalnut询问:

有什么好方法可以说服团队中持怀疑态度的开发人员相信单元测试的价值?

这里的每个人都会突然提出很多为什么单元测试很好的原因。然而,我发现说服某人的最好方法往往是 听 他们的论点,并逐点解决。如果你倾听并帮助他们用语言表达他们的担忧,你可以解决每一个问题,也许可以将他们转变为你的观点(或者至少让他们没有立足点)。 谁知道呢?也许他们会说服你为什么单元测试不适合你的情况。 不太可能,但有可能。也许,如果你发布他们反对单元测试的论点,我们可以帮助确定反驳的论点。

倾听和理解争论的双方是很重要的。如果你过于热衷于采用单元测试而不考虑人们的担忧,你最终会陷入一场宗教战争(可能真的没有价值的单元测试)。如果你慢慢地采用它,并从以最低的成本将它应用到你能看到最大好处的地方开始,你可能能够证明单元测试的价值,并有更好的机会说服人们。我意识到这并不像听起来那么容易——通常需要一些时间和仔细的衡量标准来制定一个令人信服的论点。

单元测试是一种工具,和其他任何工具一样,应该以这样一种方式应用,即收益(捕捉错误)大于成本(编写错误的努力)。如果它们没有意义,就不要使用它们,记住它们只是工具库的一部分(例如检查、断言、代码分析器、形式化方法等)。我告诉我的开发人员:

1. 如果他们有很好的论据说明为什么没有必要(例如,太简单而不值得或太困难而不值得)以及如何以其他方式验证方法(例如,检查、断言、形式化方法、交互/集成测试),他们可以跳过为方法编写测试。他们需要考虑一些验证,如检查和正式证明,是在某个时间点完成的,然后需要在每次生产代码更改时重复,而单元测试和断言可以用作回归测试(编写一次,然后重复执行)。有时我同意他们的观点,但更多时候我会争论一个方法是真的太简单还是太难进行单元测试。

   • 如果开发人员认为一个方法似乎太简单而不会失败,那么花60秒的时间为它编写一个简单的5行单元测试难道不值得吗?在接下来的一年或更长时间里,这5行代码将每晚运行(你会进行夜间构建,对吧?),即使只是碰巧发现了一个可能需要15分钟或更长时间才能识别和调试的问题,这也是值得的。此外,编写简单的单元测试会增加单元测试的数量,这会让开发人员看起来很好。

   • 另一方面,如果开发人员认为一个方法似乎太难进行单元测试(不值得付出巨大的努力),也许这是一个很好的迹象,表明需要对该方法进行划分或重构,以测试容易的部分。通常,这些方法依赖于不寻常的资源,如singleton、当前时间或外部资源,如数据库结果集。这些方法通常需要重构为一个获取资源的方法(例如调用getTime())和一个将资源作为参数的方法(如将时间戳作为参数)。我让他们跳过测试检索资源的方法,而是为现在将资源作为参数的方法编写单元测试。通常,这会使编写单元测试更加简单,因此值得编写。

2. 开发人员需要在单元测试的全面程度上划清界限。在开发后期,每当我们发现错误时,他们都应该确定更全面的单元测试是否会发现问题。如果是这样的话,如果这些bug重复出现,他们需要在未来编写更全面的单元测试(从添加或扩展当前bug的单元测试开始)。他们需要找到正确的平衡。

重要的是要意识到单元测试不是银弹 是 太多的单元测试。在我的工作场所,每当我们总结经验教训时,我不可避免地会听到“我们需要写更多的单元测试”。管理层点头表示同意,因为“单元测试”==“良好”的说法让他们大吃一惊。

然而,我们需要了解“更多单元测试”的影响。一个开发人员一周只能写大约N行代码,你需要弄清楚这些代码中单元测试代码和生产代码的比例。一个松懈的工作场所可能有10%的代码作为单元测试,90%的代码作为生产代码,导致产品具有很多(尽管非常bug)功能(想想MS Word)。另一方面,一个拥有90%单元测试和10%生产代码的严格商店将拥有一个几乎没有功能的坚如磐石的产品(想想“vi”)。你可能永远听不到关于后一种产品崩溃的报道,但这可能与产品销量不佳有关,也可能与代码质量有关。

更糟糕的是,也许软件开发中唯一确定的是“变化是不可避免的”。假设严格的车间(90%的单元测试/10%的生产代码)创建了一个恰好具有2个功能的产品(假设5%的生产代码==1个功能)。如果客户出现并更改了其中一个特性,那么该更改将破坏50%的代码(45%的单元测试和5%的生产代码)。松懈的商店(10%的单元测试/90%的生产代码)有一个有18个功能的产品,没有一个能很好地工作。他们的客户完全重新制定了他们的4项功能的要求。即使更改是原来的4倍,也只有一半的代码库被破坏(~25%=~4.4%的单元测试+20%的生产代码)。

我的观点是,你必须沟通,你明白单元测试太少和太多之间的平衡——本质上你已经考虑过问题的两面。如果你能说服你的同龄人和/或你的管理层,你就会获得信誉,也许更有机会赢得他们的支持。

我已经试过很多次单元测试了,考虑到我的情况,我仍然相信这是值得的。

我开发网站,其中大部分逻辑涉及创建、检索或更新数据库中的数据。当我试图为单元测试目的“模拟”数据库时,它变得非常混乱,似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时,从长远来看,它从来没有真正帮助过我。因为我主要是独自处理项目,所以我倾向于直观地知道代码的哪些区域可能会受到我正在处理的东西的影响,并且我手动测试这些区域。我想尽快将解决方案交付给我的客户,而单元测试通常看起来是浪费时间。我列出了手动测试,并亲自完成,边做边打勾。

我可以看到,当一个开发团队正在处理一个项目并更新彼此的代码时,这可能是有益的,但即使如此,我认为如果开发人员具有高质量,良好的沟通和编写良好的代码通常就足够了。

单元测试的一个优点是,它们可以作为代码行为的文档。好的测试有点像参考实现,队友可以查看它们,看看如何将他们的代码与您的代码集成。

单元测试非常值得初始投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:

• 回归检验 消除对 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次发生变化时都会工作或爆炸 制造)
• 可执行代码示例 对于 其他团队成员(以及您自己 六个月时间..)
• 毫不怜悯的 重构 -这是难以置信的回报,试试看!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试夹具的片段并不困难。

你应该尽量少测试!

也就是说,您应该编写足够的单元测试来揭示意图。这经常被掩盖。单元测试会让你付出代价。如果你做出改变并且你必须改变测试,那么你的敏捷性就会降低。保持单元测试简短而甜蜜。那么它们就很有价值。

我经常看到很多测试永远不会失败,它们又大又笨拙,没有太多价值,最终只会让你慢下来。

我在其他任何答案中都没有看到这一点,但我注意到的一件事是 我可以调试得更快 。你不需要用正确的步骤序列深入查看你的应用程序,就可以找到你修复的代码,结果却发现你犯了一个布尔错误,需要重新执行。使用单元测试,您可以直接进入正在调试的代码。

[我有一点要说,我看不见上面]

“每个人都在进行单元测试,但他们并不一定意识到这一点——事实”

想一想,您可以编写一个函数来解析字符串并删除换行符。作为一名新手开发人员,你可以通过在Main()中实现它,从命令行运行一些案例,或者用一个按钮拼凑一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,看看会发生什么。

这是单元测试——基本的、组合不好的,但您可以针对少数情况测试代码。

你写的东西更复杂。当您抛出一些案例(单元测试)并调试到代码中并进行跟踪时,它会抛出错误。你在经历的过程中审视价值观,并决定它们是对是错。这在某种程度上是单元测试。

这里的单元测试实际上是采用这种行为,将其正式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写一个“正确”的单元测试用例,而不是手动测试,那么它所花费的时间与您所经历的时间相同,或者可能更少,并且您可以一次又一次地重复它

多年来,我一直试图说服人们,他们需要为自己的代码编写单元测试。无论他们是先编写测试(如TDD),还是在对功能进行编码之后,我总是试图向他们解释对代码进行单元测试的所有好处。几乎没有人不同意我的观点。你不能不同意显而易见的事情,任何聪明的人都会看到单元测试和TDD的好处。

单元测试的问题在于,它需要行为的改变,而改变人们的行为是非常困难的。通过言语,你会得到很多人的同意,但你不会看到他们做事的方式有太多变化。

你必须通过做来说服别人。你个人的成功会比你所有的争论吸引更多的人。如果他们看到你不仅仅是在谈论单元测试或TDD,而是在做你所宣扬的事情,并且你成功了,人们会试图模仿你。

你还应该发挥领导作用,因为没有人第一次就写好单元测试,所以你可能需要指导他们如何做,向他们展示方法和可用的工具。在他们写第一次测试时帮助他们,复习他们自己写的测试,并向他们展示你通过自己的经历学到的技巧、习语和模式。过一段时间,他们将开始看到自己的好处,他们将改变自己的行为,将单元测试或TDD纳入他们的工具箱。

改变不会在一夜之间发生,但只要有一点耐心,你可能会实现你的目标。

测试驱动开发中经常被掩盖的一个主要部分是可测试代码的编写。起初,这似乎是一种折衷,但您会发现,可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要帮助说服别人 this 是一个关于单元测试优点的简单演示。

如果你现有的代码库不适合进行单元测试,而且它已经在生产中了,那么你可能会通过重构所有代码来制造比你解决的问题更多的问题,使其能够进行单元测试。

相反,您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA能够根据需求文档验证功能,那么就完成了。发货。

在我看来,这方面的经典示例是嵌入到链接到GridView的ASPX页面中的SqlDataReader。代码全部在ASPX文件中。SQL位于存储过程中。你的单元测试是什么?如果页面做了它应该做的事情,你真的应该把它重新设计成几个层,这样你就有了自动化的东西吗?

单元测试最棒的一点是,你的代码在进行测试时会变得更容易测试。没有测试就创建的预先存在的代码总是一个挑战,因为由于它们不是要进行单元测试的,所以类之间的高度耦合、类内难以配置的对象(如电子邮件发送服务引用)等情况并不少见。但不要让这件事让你失望!当你开始编写单元测试时,你会发现你的整体代码设计会变得更好,测试得越多,你就越有信心对它进行更多的更改,而不用担心破坏你的应用程序或引入错误。

对代码进行单元测试有几个原因,但随着时间的推移,你会发现在测试上节省的时间是最好的原因之一。在我刚刚交付的系统中,我坚持进行自动化的单元测试,尽管有人声称我花在测试上的时间要比手动测试系统多得多。我完成了所有的单元测试,在不到10分钟的时间里运行了400多个测试用例,每次我必须对代码进行一个小的更改时,我只需要10分钟就可以确保代码仍然正常工作,没有错误。你能想象一个人手动运行400多个测试用例所花费的时间吗?

当涉及到自动化测试时——无论是单元测试还是验收测试——每个人都认为,如果你计划只运行一次测试,那么手动编写代码是徒劳的,有时也是如此。自动化测试最棒的部分是,您可以毫不费力地运行它们几次,在第二次或第三次运行之后,您所花费的时间和精力 浪费 已付款。

最后一条建议是,不仅要对代码进行单元测试,还要先进行测试(请参阅 TDD 和 BDD 了解更多)

单元测试在重构或重写代码时也特别有用。如果你有很好的单元测试覆盖率,你可以放心地重构。如果没有单元测试,通常很难确保您没有破坏任何东西。

简而言之——是的。他们值得付出每一分的努力。。。到了一定程度。归根结底,测试仍然是代码,就像典型的代码增长一样,您的测试最终需要进行重构,以保持可维护性和可持续性。有一吨GOTCHAS!当涉及到单元测试时,但是天啊,天啊,什么都没有,我的意思是,nothing使开发人员能够比一组丰富的单元测试更自信地进行更改。

我现在正在做一个项目。。。。它有点TDD,我们的大部分业务规则都被封装为测试。。。我们现在有大约500个单元测试。在过去的迭代中,我不得不修改我们的数据源,以及桌面应用程序如何与该数据源接口。我花了几天时间,一直都在进行单元测试,看看我坏了什么并修复了它;构建并运行测试;把你弄坏的东西修好。清洗,冲洗,必要时重复。传统上需要几天的QA和船上的压力,而不是一次短暂而愉快的经历。

提前做好准备,付出一点额外的努力,当你不得不开始在核心功能/功能上讨价还价时,它会得到10倍的回报。

我买了这本书——这是一本关于xUnit测试知识的圣经——这可能是我书架上参考最多的书之一,我每天都会查阅: link text

偶尔,我自己或我的一位同事会花几个小时来弄清这个稍微模糊的错误,一旦发现错误的原因,90%的时间代码都没有经过单元测试。单元测试并不存在,因为开发人员为了节省时间而偷工减料,但随后却失去了这一点和更多的调试。

花少量时间编写单元测试可以节省数小时的未来调试时间。

我是一名维护工程师,负责一个文档不全、糟糕且庞大的代码库。我希望编写代码的人已经为它编写了单元测试。
每次我更改和更新生产代码时,我都害怕会因为没有考虑某些条件而引入错误。
如果他们编写测试,对代码库进行更改将更容易、更快。(同时,代码库将处于更好的状态)。。

我认为单元测试在编写api或框架时非常有用,这些api或框架必须持续多年,并由原始程序员以外的人使用/修改/开发。

单元测试绝对值得付出努力。不幸的是,您选择了一个困难的(但不幸的是常见的)场景来实现它。

单元测试的最大好处是从头开始使用它——在一些精选的小项目中,我很幸运在实现类之前编写了单元测试(此时接口已经完成)。有了适当的单元测试,你会在类中发现并修复它们,而它们还处于初级阶段,而且不会接近它们将来无疑会集成到的复杂系统。

如果您的软件是稳固的面向对象的,那么您应该能够在类级别添加单元测试,而不需要太多努力。如果你没有那么幸运,你仍然应该尽可能地结合单元测试。当你添加新的功能时,确保新的部分定义良好,界面清晰,你会发现单元测试让你的生活更轻松。

当你说“我们的代码库不适合简单的测试”时,这是代码气味的第一个迹象。编写单元测试意味着您通常会以不同的方式编写代码,以使代码更易于测试。在我看来,这是一件好事,因为这些年来,我在编写代码时看到了我必须为之编写测试,这迫使我提出了一个更好的设计。

我不知道。很多地方不做单元测试,但代码的质量很好。微软做单元测试,但比尔·盖茨在演讲中给出了一个蓝色屏幕。

我写了一篇关于这个话题的博客文章。我发现,单靠单元测试是不值得的,而且通常在截止日期临近时会被削减。

我们不应该从“一次又一次的测试”验证的角度来谈论单元测试,而应该看看在实现之前编写规范/测试/想法时发现的真实值。

这个简单的想法改变了我编写软件的方式,我不会再回到“旧”的方式。

How test first development changed my life

是的——单元测试绝对值得付出努力,但你应该知道这不是银弹。单元测试是一项工作,随着代码的变化,你必须努力保持测试的更新和相关性,但所提供的价值值得你付出努力。重构而不受惩罚的能力是一个巨大的好处,因为你可以在任何代码更改后运行测试来验证功能。诀窍是不要太纠结于你正在测试的工作单元,或者你是如何构建测试需求的,当单元测试真的是一个功能测试时,等等。人们会连续几个小时争论这件事,而事实是,你在编写代码时所做的任何测试都比不做要好。另一条公理是关于质量而不是数量的——我看到过1000个测试的代码库基本上没有意义,因为其余的测试并没有真正测试任何有用的或任何特定领域的东西,比如业务规则,等等。我也见过代码覆盖率为30%的代码库,但这些测试是相关的、有意义的,而且非常棒,因为它们测试了代码的核心功能,并表达了代码应该如何使用。

在探索新框架或代码库时,我最喜欢的技巧之一是为“it”编写单元测试,以发现事物是如何工作的。这是一个了解更多新事物的好方法,而不是阅读枯燥的文档:)

我最近在工作场所经历了完全相同的经历,发现他们中的大多数人都知道理论上的好处,但必须特别向他们推销这些好处,所以我(成功地)使用了以下几点:

• 它们在执行负测试时节省了时间,在负测试中,您可以处理意外输入(空指针、越界值等),因为您可以在一个进程中完成所有这些操作。
• 它们在编译时提供有关更改标准的即时反馈。
• 它们对于测试在正常运行时可能不会公开的内部数据表示非常有用。

大的。。。

• 你可能不需要单元测试,但当其他人在没有完全理解的情况下修改代码时,他们可能会犯很多愚蠢的错误。

几年前,我发现了TDD,并用它编写了我喜欢的所有项目。我估计,TDD一个项目所需的时间与将其组合在一起所需的大致相同,但我对最终产品的信心越来越大,以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更注重界面,以防我需要一起模仿),正如顶部的绿色帖子所写,它有助于解决“编码便秘”:当你不知道下一步该写什么,或者你面前有一项艰巨的任务时,你可以写得很小。

最后,我发现到目前为止,TDD最有用的应用程序是在调试中,哪怕只是因为您已经开发了一个询问性框架,使用该框架可以促使项目以可重复的方式产生错误。

有一件事还没有人提到,那就是让所有开发人员承诺实际运行和更新任何现有的自动化测试。由于新的开发,自动测试会失去很多价值,并使自动测试变得非常痛苦。由于开发人员已经手动测试了代码,所以这些测试中的大多数都不会指示错误,因此更新代码所花费的时间只是浪费。

说服怀疑论者不要破坏其他人在单元测试中所做的工作,对于从测试中获得价值来说更重要,也可能更容易。

每次从存储库更新时,花费数小时更新因新功能而中断的测试既不高效,也不有趣。

如果您正在使用NUnit,那么一个简单但有效的演示就是在它们前面运行NUnit自己的测试套件。看到一个真正的测试套件给一个代码库一个锻炼是值得千言万语的。。。

单元测试对任何一个开发人员都无法想象的项目都有很大帮助。它们允许您在签入之前运行单元测试套件,并发现您是否损坏了什么。这减少了 大量 在等待别人修复他们签入的错误时,你不得不坐在那里无所事事,或者为了完成一些工作而恢复他们的更改。它在重构中也非常有价值,因此您可以确保重构后的代码通过了原始代码所做的所有测试。

使用单元测试套件,可以对代码进行更改,同时保留其余功能。这是一个很大的优势。当您完成新特性的编码时,您是否使用单元测试sutie和回归测试套件。

我同意与大多数人相反的观点: It's OK Not to Write Unit Tests 特别是重原型编程(例如AI)很难与单元测试相结合。