it-swarm.cn

单元测试值得付出努力吗?

我正在努力将单元测试集成到我工作的团队的开发过程中,并且有一些怀疑论者。有什么好的方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将添加单元测试,因为我们添加功能或修复了错误。不幸的是,我们的代码库不适合简单的测试。

573
Ross Fuhrman

我们办公室的每一天都有一个类似这样的交流:

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

细节每天都在变化,但情绪却没有。单元测试和测试驱动开发(TDD)有很多隐藏的和个人的好处,以及你自己无法真正解释的明显的好处,直到他们自己做。

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

  1. 单元测试允许您快速对代码进行大的更改。你知道它现在有效,因为你已经运行了测试,当你需要进行更改时,你需要让测试再次运行。这节省了数小时。

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

  3. 测试和代码协同工作以实现更好的代码。你的代码可能很糟糕/错误。你的测试可能很糟糕/错误。在TDD中,你可以依赖于 两者 坏/错误低的机会。通常这是需要修复的测试,但这仍然是一个好结果。

  4. TDD有助于编码便秘。如果面对大量艰巨的工作,写下测试将让你快速前进。

  5. 单元测试可以帮助您真正理解您正在使用的代码的设计。您不是编写代码来执行某些操作,而是首先概述您要对代码进行处理的所有条件以及您希望从中获得的输出。

  6. 单元测试为您提供即时的视觉反馈,当我们完成时,我们都喜欢所有绿灯的感觉。这非常令人满意。在中断之后离开的位置也更容易,因为你可以看到你需要去的地方 - 下一个需要修理的红灯。

  7. 与流行的观点相反,单元测试并不意味着编写两倍的代码,或编码速度较慢。一旦你掌握了它,它比没有测试的编码更快,更强大。测试代码本身通常是相对微不足道的,并不会给你正在做的事情增加很大的开销。这是你在这样做时才会相信的:)

  8. 我认为Fowler说:“不完美的测试,经常运行,比完全没有写过的完美测试要好得多”。我将此解释为允许我编写测试,我认为它们将是最有用的,即使我的其余代码覆盖率非常不完整。

  9. 良好的单元测试可以帮助记录和定义应该做的事情

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

我参与的很多工作都没有单元测试(Web应用程序用户交互等),但即便如此,我们都在本店测试感染,并且当我们的测试被绑定时最开心。我不能高度推荐这种方法。

722
reefnet_alex

单元测试很像去健身房。 你知道它对你有好处,所有的论点都有意义,所以你开始锻炼了。有一个最初的拉什,这是伟大的,但几天后你开始怀疑是否值得的麻烦。你需要一个小时的时间来换衣服,然后在仓鼠轮上跑步,你不确定除了腿部和手臂疼痛之外你还得不到任何其他东西。

然后,在一两周之后,就像疼痛消失一样,大截止日期即将开始。你需要花费每个醒着的时间来完成“有用”的工作,这样你就可以减少无关紧要的东西,比如去健身房。你没有这个习惯,当大截止日期结束时,你又回到原点。如果你设法让它回到健身房,你会感觉像第一次去的那样疼痛。

你做一些阅读,看看你做错了什么。你开始感到一点点非理性的厌恶,所有的健康,快乐的人颂扬运动的美德。你意识到你并没有很多共同之处。他们不需要开15分钟就可以去健身房;他们的建筑物中有一个。他们不必与任何人争论运动的好处;这只是每个人所做的事情并且接受同样重要的事情。当一个大截止日期临近时,他们不会被告知锻炼是不必要的,而不是你的老板会要求你停止进食。

所以,为了回答你的问题,单元测试通常是值得的,但所需的工作量并不是每个人都相同。 单元测试可能需要付出巨大的努力,如果您在公司中处理意大利面条代码库,而不是 实际上 重视代码质量。 (许多管理人员会赞扬单元测试的赞誉,但这并不意味着他们会在重要的时候坚持下去。)

如果您正在尝试将单元测试引入您的工作中并且没有看到您所期望的所有阳光和彩虹,请不要责怪自己。您可能需要找到一份新工作才能真正让Unit Testing为您服务。

421
benzado

说服的最好方法...找一个bug,为它编写一个单元测试,修复bug。

那个特定的bug不太可能再次出现,你可以用你的测试证明它。

如果你做得足够好,其他人就会很快流行起来。

136
Ed Guiness

thetalkingwalnut问:

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

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

倾听并理解论证的两个方面很重要。如果你试图过于热心地采用单位测试而不考虑人们的担忧,你最终会发生宗教战争(可能真的毫无价值的单位测试)。如果你慢慢采用它并开始应用它,你将看到最低成本的最大利益,你可能能够证明单元测试的价值,并有更好的机会说服人们。我意识到这并不像听起来那么容易 - 通常需要一些时间和细致的指标来制定令人信服的论点。

单元测试是一种工具,与任何其他工具一样,应该以这样的方式应用,即利益(捕获错误)超过成本(编写它们的努力)。如果/它们没有意义,请不要使用它们并记住它们只是您工具库的一部分(例如检查,断言,代码分析器,正式方法等)。我告诉我的开发人员是这样的:

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

    • 如果一个开发人员认为方法看起来太简单而不能失败,那么为它写一个简单的5行单元测试是否值得花60秒的时间?这5行代码将每晚运行(你做夜间构建,对吧?),对于明年或更长时间,即使只是一次碰到可能需要花费15分钟或更长时间来识别的问题,这些代码也是值得的。和调试。此外,编写简单单元测试可以提高单元测试的数量,从而使开发人员看起来很好。

    • 另一方面,如果开发人员认为方法似乎太难以进行单元测试(不值得花费大量精力),也许这表明需要对方法进行划分或重构以测试简单部分。通常,这些方法依赖于异常资源,如单例,当前时间或外部资源(如数据库结果集)。这些方法通常需要重构为获取资源的方法(例如,调用getTime())和将资源作为参数的方法(例如,将时间戳作为参数)。我让他们跳过测试检索资源的方法,然后他们为现在将资源作为参数的方法编写单元测试。通常,这使得编写单元测试变得更加简单,因此值得编写。

  2. 开发人员需要在他们的单元测试应该是多么全面的情况下画出“沙滩线”。在开发的后期,每当我们发现错误时,他们应该确定更全面的单元测试是否会遇到问题。如果是这样,并且如果这些错误反复出现,他们需要将“线”移动到将来编写更全面的单元测试(从添加或扩展当前错误的单元测试开始)。他们需要找到合适的平衡点。

实现单元测试的重要性不是银弹,并且这样的事情,如单元测试太多。在我的工作场所,每当我们吸取教训时,我都不可避免地听到“我们需要编写更多单元测试”。管理层点头表示同意,因为它被“单元测试”=“好”打成了他们的头脑。

但是,我们需要了解“更多单元测试”的影响。开发人员每周只能写出~N行代码,你需要弄清楚该代码应该是单位测试代码与生产代码的百分比。宽松的工作场所可能有10%的代码作为单元测试,90%的代码作为生产代码,导致产品具有很多(虽然非常多的)功能(想想MS Word)。另一方面,一个拥有90%单元测试和10%生产代码的严格商店将拥有极少数功能的坚如磐石的产品(想想“vi”)。您可能永远不会听到关于后一种产品崩溃的报告,但这可能与产品的销售情况不同,因为它与代码的质量有很大关系。

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

我的观点是,你必须要沟通,你才能理解在太少和太多的单元测试之间的平衡 - 基本上你已经考虑过问题的两个方面。如果你可以说服你的同行和/或你的管理层,你就会获得可信度,也许有更好的机会赢得他们。

69
Bert F

我已多次玩过单元测试,但我仍然相信,鉴于我的情况,这是值得的。

我开发网站,其中许多逻辑涉及创建,检索或更新数据库中的数据。当我试图“模拟”数据库进行单元测试时,它已经非常混乱,似乎有点无意义。

当我编写关于业务逻辑的单元测试时,从长远来看它从来没有真正帮助过我。因为我主要在项目上工作,所以我倾向于直观地知道哪些代码区域可能会受到我正在处理的事情的影响,我会手动测试这些区域。我想尽快为我的客户提供解决方案,单元测试通常似乎是浪费时间。我列出了手动测试并自己走过它们,随时随地勾选它们。

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

38
Ronnie

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

31
pkaeding

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

  • 回归测试 消除了对代码进行更改的恐惧(没有什么比看到代码工作的温暖光芒或每次进行更改时都会爆炸)
  • 可执行代码示例 对于其他团队成员(以及六个月后的自己......)
  • merciless refactoring - 这是非常有益的,试试吧!

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

26
Jonathan Webb

你应该尽可能少地测试!

意思是,你应该编写足够的单元测试来揭示意图。这经常被掩盖。单元测试会花费你。如果您进行更改并且必须更改测试,则不太灵活。保持单元测试简短而甜蜜。然后他们有很多价值。

我经常看到许多测试永远不会破坏,大而笨拙并且没有提供很多价值,它们最终会让你失望。

25
Keith Nicholas

我没有在任何其他答案中看到这一点,但我注意到的一件事是 我可以更快地调试 。您不需要通过正确的步骤深入了解您的应用程序以获取您修复的代码,只是发现您发生了布尔错误并需要再次执行此操作。通过单元测试,您可以直接进入正在调试的代码。

23
John MacIntyre

[我有一点让我无法看到上面]

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

想一想,你编写一个函数来解析一个字符串并删除换行符。作为一个新手开发人员,您可以通过在Main()中实现它来从命令行运行一些案例,或者将视觉前端与按钮组合在一起,将您的函数绑定到几个文本框和一个按钮,然后查看怎么了。

这是单元测试 - 基本和非常合理,但你测试了一些代码的代码。

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

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

21
Chris Gill

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

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

你必须通过这样做来说服人们。你的个人成功将吸引更多的人,而不是你可能拥有的所有论点。如果他们发现你不只是在谈论单元测试或TDD,而是你正在做你所宣讲的,并且你成功了,人们会试着模仿你。

您还应该担任主角,因为没有人在第一时间正确编写单元测试,因此您可能需要指导他们如何操作,向他们展示方式以及可用的工具。在他们编写第一次测试时帮助他们,查看他们自己编写的测试,并向他们展示您通过自己的经历学到的技巧,习语和模式。过了一段时间,他们将开始自己看到好处,他们将改变他们的行为,将单元测试或TDD纳入他们的工具箱。

变化不会在一夜之间发生,但只要有一点耐心,您就可以实现目标。

16
Curro

经常被掩盖的测试驱动开发的一个主要部分是编写可测试代码。它起初似乎是一种妥协,但你会发现可测试的代码最终也是模块化的,可维护的和可读的。如果你仍然需要帮助说服人们 这个 是关于单元测试优势的简单介绍。

12
Tom Martin

如果您现有的代码库不适合单元测试,而且它已经在生产中,那么您可能会通过尝试重构所有代码来创建比解决方案更多的问题,以便它可以进行单元测试。

您可能最好还是努力改进集成测试。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。装运它。

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

11
Eric Z Beard

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

对您的代码进行单元测试有几个原因,但随着时间的推移,您会发​​现节省测试时间是执行此操作的最佳理由之一。在我刚刚交付的系统中,尽管声称我花费更多时间进行测试而不是手动测试系统,但我坚持进行自动化单元测试。完成所有的单元测试后,我在不到10分钟的时间内运行了400多个测试用例,每次我不得不对代码进行一些小的更改,我只需要确保代码仍在工作,没有错误就是十分钟。你能想象用手动这400多个测试用例的时间吗?

当涉及到自动化测试 - 无论是单元测试还是验收测试 - 每个人都认为,如果您计划仅运行一次测试,那么手动编写可以执行的操作就会浪费精力,有时这是真的。自动化测试的最佳部分是您可以毫不费力地多次运行它们,在第二次或第三次运行后,您已经支付了浪费的时间和精力。

最后一条建议是不仅要对你的代码进行单元测试,而且要先开始测试(参见 _ tdd __ bdd _ 了解更多信息)

10
Alexandre Brasil

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

8
killdash10

我是一名维护工程师,负责一个记录不完整,可怕且代码量大的代码库。我希望编写代码的人编写了单元测试。
每次我做出更改并更新生产代码时,我都害怕因为没有考虑某些条件而引入错误。
如果他们写了测试,那么对代码库的更改将更容易,更快。(同时代码库将处于更好的状态)。

我认为单元测试在编写必须持续多年的api或框架以及由原始编码器以外的人使用/修改/演化时证明非常有用。

7
mic.sca

简而言之 - 是的。他们值得每一分努力......到了一定程度。在一天结束时,测试仍然是代码,就像典型的代码增长一样,您的测试最终需要进行重构才能实现可维护性和可持续性。有一吨GOTCHAS!当涉及到单元测试时,但男人哦,男人哦,没什么,我的意思是没有让开发人员能够比一套丰富的单元测试更自信地进行更改。

我现在正在开展一个项目......它有点像TDD,而且我们的大部分业务规则都被认为是测试...我们现在有大约500个左右的单元测试。在过去的迭代中,我不得不改进我们的数据源以及我们的桌面应用程序如何与该数据源进行交互。花了几天时间,我一直在进行单元测试,看看我打破了什么并修好了。做出改变;构建并运行测试;修复你破坏的东西。洗涤,冲洗,必要时重复。传统上需要几天的质量保证和船只压力是一个简短而愉快的体验。

事先做好准备,做一点额外的努力,当你不得不开始使用核心功能/功能时,它可以支付10倍的费用。

我买了这本书 - 它是xUnit测试知识的圣经 - 这可能是我书架上参考最多的书之一,我每天都会查阅: 链接文字

7
cranley

偶尔我自己或我的一个同事会花费几个小时到达稍微模糊的bug的底部,一旦发现错误的原因,90%的时间代码未经过单元测试。单元测试不存在,因为开发人员正在偷工减料以节省时间,但随后又失去了这个和更多的调试。

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

7
Jon Cahill

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

6
Keith Elder

我不知道。很多地方不做单元测试,但代码质量很好。微软确实进行了单元测试,但比尔盖茨在他的演讲中给出了蓝屏。

6
BigTiger

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

您将获得的单元测试的最大好处是从头开始使用它 - 在一些选择的小项目中,我有幸在实现我的类之前编写单元测试(接口已经完成了点)。通过适当的单元测试,您可以在课程中找到并修复错误,同时它们仍处于初级阶段,而不是在复杂系统附近的任何地方,它们无疑将在未来集成。

如果您的软件是面向对象的,那么您应该能够在课堂级别添加单元测试而无需太多精力。如果您不是那么幸运,您仍应尝试在任何地方进行单元测试。确保在添加新功能时,新的部件已经通过清晰的界面进行了明确定义,您会发现单元测试可以让您的生活更轻松。

6
Matt

我写了一篇关于这个主题的非常大的博客文章。我发现单独的单元测试不值得工作,并且在截止日期越来越近时通常会被削减。

我们不应该从“测试后”验证的角度讨论单元测试,而应该看看在开始实现之前编写规范/测试/想法时发现的真正价值。

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

测试第一次开发如何改变了我的生活

5
Toran Billups

没有人提到的一件事是让所有开发人员承诺实际运行和更新任何现有的自动化测试。由于新的开发而您回到并发现损坏的自动化测试会失去很多价值并使自动化测试变得非常痛苦。由于开发人员手动测试了代码,因此大多数测试都不会显示错误,因此更新它们所花费的时间只是浪费。

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

每次从存储库更新时,花费数小时更新因新功能而损坏的测试既不高效又无趣。

3
Samuel Åslund

几年前我发现了TDD,并且已经使用它编写了我所有的宠物项目。我估计TDD项目花费大致相同的时间,因为它需要一起牛仔,但我对最终产品的信心增强,我无法帮助你获得成就感。

我也觉得它改善了我的设计风格(更多面向界面,以防我需要一起模拟的东西),并且,作为顶部的绿色帖子写,它有助于“编码便秘”:当你不知道什么写下一个,或者你面前有一项艰巨的任务,你可以写小。

最后,我发现到目前为止TDD最有用的应用是在调试中,只是因为你已经开发了一个询问框架,你可以利用它来刺激项目以可重复的方式产生bug。

3
Kaz Dragon

是的 - 单元测试绝对是值得的,但你应该知道它不是一颗银弹。单元测试是有效的,你必须努力保持测试更新和相关的代码更改,但提供的价值是值得你付出的努力。重构的能力不受惩罚是一个巨大的好处,因为你总是可以验证功能通过在任何更改代码之后运行测试。诀窍是不要过于依赖于您正在测试的工作单元或者您是如何构建测试要求以及单元测试是否真的是功能测试等等。人们会争论这些东西几个小时最后,现实是你作为写代码做的任何测试都比不做它更好。另一个公理是关于质量而不是数量 - 我已经看到基于1000的测试的代码库本质上没有意义,因为其余的没有真正测试任何有用的或特定领域的特定领域,如特定领域的业务规则等。我还看到代码库有30%的代码覆盖率,但测试是相关的,有意义的,非常棒,因为他们测试了代码编写的代码的核心功能,并表达了应该如何使用代码。

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

3
Vinny Carpenter

我最近在我的工作场所经历了完全相同的经历,并发现他们中的大多数人都知道理论上的好处,但必须特别为他们带来好处,所以这里是我使用的点(成功):

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

而那个大人物......

  • 您可能不需要进行单元测试,但是当其他人进来并且在没有完全理解的情况下修改代码时,它可以捕获他们可能犯下的许多愚蠢的错误。
3
dlanod

根据我的经验,单元测试和集成测试在复杂的软件环境中是“必须的”。

为了说服团队中的开发人员编写单元测试,您可能需要考虑在开发环境中集成单元测试回归分析(例如,在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败,他们就不必花费太多时间来调试它来发现问题,他们会更鼓励他们编写它们。

这是一个提供此类功能的工具:

单元测试回归分析工具

2
Liorp

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

2
Garth Gilmour

关于单元测试要记住的一件事是它对开发人员来说是一种安慰。

相比之下,功能测试适用于用户:每当您添加功能测试时,您都在测试用户将看到的内容。当您添加单元测试时,您只是让开发人员的生活更轻松。在这方面,这有点奢侈。

当您必须在编写单元或功能测试之间做出选择时,请记住这种二分法。

2
Cedric Beust

我同意与大多数人相反的观点: 可以不编写单元测试 特别是原型大量编程(例如AI)很难与单元测试结合使用。

2
DSblizzard

单元测试对于比任何一个开发人员都能掌握的项目更大的项目有很大帮助。它们允许您在签入之前运行单元测试套件,并发现您是否损坏了某些东西。这样可以减少 lot 在等待其他人修理他们检查过的错误时不得不坐下来转动拇指的情况,或者为了恢复他们的改变而烦恼,这样你就可以完成一些工作了。它在重构方面也非常有价值,因此您可以确保重构的代码通过了原始代码所做的所有测试。

2
Max Rible Kaehn

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

2
Shinwari

单元测试的重点是使测试变得容易。它是自动化的。 “做出测试”,你就完成了。如果您遇到的问题之一难以测试代码,那么这是所有使用单元测试的最佳理由。

1
Deathbob

就在今天,我不得不改变之前编写过单元测试的类。
测试本身写得很好,包括我甚至没想过的测试场景。
幸运的是,所有测试都通过了,我的更改得到了快速验证,并充满信心地进入了测试环境。

1
crowne

手动测试软件时,通常会使用一小组测试/操作。最终,您将自动变形您的输入数据或操作,以便您自己解决已知问题。单元测试应该在那里提醒你事情不能正常工作。

我建议在代码之前编写测试,添加新的测试/数据来改进主代码的功能!

1
Ray Hayes

作为一名物理专业的学生,​​我非常喜欢实际的 证明 我的代码按照预期的方式工作。您可以逻辑地证明这一点,随着实现变得更加复杂,这会大大增加难度,或者您可以通过良好的测试来制作(尽可能接近)功能的经验证明。

如果您不提供功能的逻辑证明,则必须进行测试。唯一的选择是说“我认为代码有效......”

1
Fredrik

@George Stocker“不幸的是,我们的代码库不适合轻松测试。”每个人都同意单元测试有好处,但听起来这个代码库的成本很高。如果成本高于收益,那么他们为什么要对此充满热情呢?听你的同事说;也许对于他们来说,单元测试的感知痛苦大于单元测试的感知价值。

具体来说,尝试尽快获得价值,而不是一些感觉goodery“xUnit是绿色”的价值,但用户和维护者的价值清晰的代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得付出努力。

1
Trystan Spangler

使您测试的第一件事与单元测试无关。我主要在Perl工作,所以这些是Perl特定的例子,但你可以适应。

  • 每个模块是否正确加载和编译?在Perl中,这是为代码库中的每个Foo.pm创建一个Foo.t的问题:

    use_ok( 'Foo' );
    
  • 是否所有POD(Plain Ol'文档)格式正确?使用Test :: Pod验证所有文件中所有POD格式的有效性。

你可能不认为这些是大事,但它们不是,但我可以保证你会抓住一些污点。当这些测试每小时运行一次,并且它会抓住某人的过早提交时,你会有人说“嘿,这很酷”。

1
Andy Lester

单元测试的好处之一是可预测性。

在进行单元测试之前,我可以准确地预测编写代码需要多长时间,而不是我需要多长时间来调试它。

这些天,因为我可以计划我要编写的测试,我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预测性,消除了很多压力,但仍然保留了所有的快乐!.

1
Raz

单元测试是高质量代码最常用的方法之一。它对更稳定,独立和文档化的代码的贡献得到了充分证明。单元测试代码被视为存储库的一个组成部分,因此需要开发和维护。但是,开发人员经常会遇到这样一种情况:投入单元测试的资源并不像人们期望的那样富有成效。在一个理想的世界中,我们编写的每个方法都会有一系列测试,覆盖它的代码并验证它的正确性。但是,通常由于时间限制,我们要么跳过一些测试,要么写出质量差的测试。在这样的现实中,在牢记投入单元测试开发和维护的资源量的同时,必须考虑到可用时间,哪个代码值得测试最多?从现有的测试中,哪些测试实际上值得保留和维护?见 here

0
RoiG

单元测试可帮助您以更少的错误发布软件,同时降低总体开发成本。您可以点击链接阅读更多关于 单元测试的好处

0
Steve_0

你想说服谁?工程师或经理?如果您试图说服您的工程师同事,我认为您最好的选择是吸引他们制作高质量软件的愿望。有许多研究表明它发现了错误,如果他们关心做好工作,那对他们来说应该足够了。

如果您试图说服管理层,您很可能必须做某种成本/收益推理,说明未检测到的缺陷成本高于编写测试的成本。一定要包括可扣除的费用,例如失去客户信心等。

0
Craig H

这是以.Net为中心的,但有人试过 Pex

在我尝试之前,我非常怀疑 - 哇,这是什么表演。在我开始思考之前“我不会被这个概念说服,直到我理解它实际上是让我受益”。我花了一个小时才改变主意并说“我不关心你怎么知道那里有致命异常的风险,但是现在我知道了我必须处理它“

也许这种行为的唯一缺点是它会标记所有并给你六个月的积压。但是,如果你有代码债务,你总是有代码债务,你只是不知道它。告诉PM当你意识到几十个是一个令人讨厌的前景之前,有潜在的二十万点失败,这意味着这个概念至关重要{先解释一下。

0
Tom W