unit-testing - 单元测试值得努力吗？

Question

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

Answer 1

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

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

细节每天都在变化，但情绪不会。单元测试和测试驱动开发 (TDD) 有很多隐藏的和个人的好处，也有很多显而易见的好处，除非他们自己做，否则你无法真正向他们解释。

但是，忽略这一点，这是我的尝试！

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

2. TDD 帮助您了解何时停止编码。您的测试让您确信您现在已经完成了足够多的工作，并且可以停止调整并继续下一步。

3. 测试和代码协同工作以实现更好的代码。您的代码可能不好/有问题。你的测试可能是坏的/错误的。在 TDD 中，您寄希望于坏/错误的可能性都较低。通常是需要修复的测试，但这仍然是一个很好的结果。

4. TDD 有助于编码便秘。当面临一项庞大而艰巨的工作时，编写测试将使您快速前进。

5. 单元测试可以帮助你真正理解你正在处理的代码的设计。您无需编写代码来做某事，而是首先概述您使代码受到的所有条件以及您期望从中得到什么输出。

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

7. 与流行的看法相反，单元测试并不意味着编写两倍的代码，或者编写更慢的代码。一旦掌握了窍门，它就会比没有测试的编码更快、更健壮。测试代码本身通常是相对微不足道的，不会给你正在做的事情增加很大的开销。这是你只有在做的时候才会相信的：）

8. 我认为是 Fowler 说的：“经常运行的不完美测试比从未编写过的完美测试要好得多”。我将此解释为允许我在我认为它们最有用的地方编写测试，即使我的其余代码覆盖范围非常不完整。

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

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

我参与的很多工作都不能很好地进行单元测试（Web 应用程序用户交互等），但即便如此，我们都在这家商店中被测试感染，当我们完成测试时最开心。我不能高度推荐这种方法。

Answer 2

单元测试很像去健身房。 你知道这对你有好处，所有的论点都有道理，所以你开始锻炼。有一个最初的匆忙，这很好，但几天后你开始怀疑这是否值得麻烦。你每天要花一个小时换衣服，在仓鼠轮上奔跑，但除了腿和手臂酸痛之外，你不确定自己是否真的得到了什么。

然后，大概一两周后，就在疼痛消失的时候，一个大截止日期开始临近。你需要在醒着的每个小时都努力完成“有用的”工作，所以你要减少无关的事情，比如去健身房。你养成了习惯，当大截止日期结束时，你又回到了原点。如果你设法回到健身房，你会感觉和第一次去时一样酸痛。

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

因此，为了回答您的问题，单元测试通常值得付出努力，但每个人所需的努力程度并不相同。 如果您在一家实际上并不重视代码质量的公司处理意大利面条式代码库，则单元测试可能需要付出巨大的努力。（很多经理会歌颂单元测试，但这并不意味着他们会在重要的时候坚持下去。）

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

Answer 3

说服的最佳方法...找到一个错误，为它编写一个单元测试，修复错误。

该特定错误不太可能再次出现，您可以通过测试证明这一点。

如果你做到这一点，其他人会很快赶上。

Answer 4

会说话的核桃问道：

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

这里的每个人都会突然想出很多为什么单元测试是好的原因。然而，我发现说服某人某事的最佳方式通常是倾听他们的论点并逐点解决。如果你倾听并帮助他们表达他们的担忧，你可以解决每一个问题，并可能将它们转化为你的观点（或者至少让他们没有立足之地）。谁知道？也许他们会说服你为什么单元测试不适合你的情况。不太可能，但可能。也许如果你发表他们反对单元测试的论点，我们可以帮助确定反对论点。

倾听和理解争论的双方很重要。如果您尝试过分热心地采用单元测试而不考虑人们的担忧，那么您最终会引发一场宗教战争（并且可能真的毫无价值的单元测试）。如果您慢慢采用它并开始将其应用到您会以最少的成本获得最大收益的地方，您可能能够展示单元测试的价值并有更好的机会说服人们。我意识到这并不像听起来那么容易——它通常需要一些时间和仔细的指标来制定一个令人信服的论点。

单元测试和其他任何工具一样，都是一种工具，并且应该以收益（捕获错误）超过成本（编写它们的努力）的方式应用。如果/在没有意义的情况下不要使用它们，并记住它们只是您工具库的一部分（例如检查、断言、代码分析器、形式方法等）。我告诉我的开发人员是这样的：

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

   • 如果开发人员认为一个方法似乎太简单而不会失败，那么花 60 秒时间为它编写一个简单的 5 行单元测试难道不值得吗？这 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% 的生产代码）。

我的观点是你必须传达你理解单元测试太少和太多之间的平衡——本质上你已经考虑了问题的两个方面。如果你能说服你的同行和/或你的管理层，你就会获得可信度，也许更有机会赢得他们的支持。

Answer 5

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

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

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

我可以看到，当一组开发人员在一个项目上工作并相互更新代码时，这可能是有益的，但即便如此，我认为如果开发人员素质很高，良好的沟通和编写良好的代码通常就足够了.

Answer 6

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

Answer 7

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

• 回归测试消除了对代码更改的恐惧（没有什么比每次更改时看到代码工作或爆炸的温暖光芒）
• 其他团队成员的可执行代码示例（以及六个月后的您自己..）
• 无情的重构——这是令人难以置信的回报，试试吧！

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

Answer 8

你应该尽可能少地测试！

意思是，您应该编写足够的单元测试来揭示意图。这经常被掩盖。单元测试会让你付出代价。如果您进行更改并且必须更改测试，那么您将变得不那么敏捷。保持单元测试简短而甜蜜。然后他们有很多价值。

我经常看到很多测试永远不会失败，又大又笨，而且没有提供很多价值，它们最终只会拖慢你的速度。

Answer 9

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

Answer 10

[我有一点我在上面看不到]

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

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

那是单元测试——基本的和糟糕的组合，但是你在少数情况下测试了一段代码。

你写一些更复杂的东西。当您通过（单元测试）抛出一些案例并且您调试代码和跟踪时，它会抛出错误。您在经历时会查看价值观并决定它们是对还是错。这在某种程度上是单元测试。

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

Answer 11

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

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

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

您还应该担任领导角色，因为没有人第一次就正确地编写单元测试，因此您可能需要指导他们如何去做，向他们展示方法以及可供他们使用的工具。在他们编写第一个测试时帮助他们，审查他们自己编写的测试，并向他们展示您通过自己的经验学到的技巧、习语和模式。一段时间后，他们会开始自己看到好处，他们会改变自己的行为，将单元测试或 TDD 合并到他们的工具箱中。

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

Answer 12

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

Answer 13

如果您现有的代码库不适合进行单元测试，并且它已经投入生产，那么您可能会通过尝试重构所有代码以使其可进行单元测试来解决比您解决的问题更多的问题。

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

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

Answer 14

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

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

当谈到自动化测试时——无论是单元测试还是验收测试——每个人都认为编写你可以手动执行的代码是一种浪费，有时这是真的——如果你打算只运行一次测试。自动化测试最好的部分是你可以毫不费力地多次运行它们，而在第二次或第三次运行之后，你所浪费的时间和精力就已经得到了回报。

最后一条建议是不仅要对您的代码进行单元测试，而且要先开始进行测试（有关更多信息，请参阅TDD和BDD）

Answer 15

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

Answer 16

简而言之 - 是的。他们值得每一盎司的努力......在一定程度上。最终，测试仍然是代码，并且与典型的代码增长非常相似，您的测试最终将需要重构以保持可维护性和可持续性。有一吨的GOTCHAS！当谈到单元测试时，但是 man oh man oh man，什么都没有，我的意思是没有什么比一组丰富的单元测试更能让开发人员更自信地进行更改。

我现在正在做一个项目……它有点 TDD，我们将大部分业务规则封装为测试……我们现在有大约 500 个左右的单元测试。在过去的迭代中，我不得不修改我们的数据源以及我们的桌面应用程序与该数据源的接口方式。花了我几天的时间，我一直在运行单元测试，看看我破坏了什么并修复了它。做出改变; 构建并运行您的测试；修复你破坏的东西。洗涤，冲洗，必要时重复。传统上需要几天的质量保证和大量的压力，而不是短暂而愉快的体验。

提前做好准备，付出一点额外的努力，然后当你必须开始使用核心特性/功能时，它会付出 10 倍的代价。

我买了这本书——它是 xUnit 测试知识的圣经——这可能是我书架上被引用最多的书之一，我每天都在查阅它： link text

Answer 17

有时，我自己或我的一位同事会花费几个小时来找出稍微晦涩的错误，一旦找到错误的原因，90% 的代码都没有经过单元测试。单元测试不存在，因为开发人员正在偷工减料以节省时间，但随后失去了这个和更多的调试。

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

Answer 18

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

我认为单元测试在编写必须持续多年并由原始编码人员以外的人使用/修改/发展的 API 或框架时证明是非常有用的。

Answer 19

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

您将从单元测试中获得的最大好处是从头开始使用它 - 在一些精选的小型项目中，我很幸运地在实现我的类之前编写了单元测试（接口已经完成了观点）。通过适当的单元测试，您将发现并修复类中的错误，而它们仍处于起步阶段，而不是靠近复杂系统的任何地方，它们无疑将在未来集成到其中。

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

Answer 20

当您说“我们的代码库不适合轻松测试”时，这是代码异味的第一个迹象。编写单元测试意味着您通常会以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写必须为其编写测试的代码时所看到的，它迫使我提出更好的设计。

Answer 21

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

Answer 22

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

与其从“test-after”验证的角度讨论单元测试，我们应该着眼于在实施之前着手编写规范/测试/想法时发现的真正价值。

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

测试优先开发如何改变了我的生活

Answer 23

是的 - 单元测试绝对值得付出努力，但你应该知道它不是灵丹妙药。单元测试是一项工作，您必须努力使测试保持更新并随着代码更改而保持相关性，但所提供的价值值得您付出努力。不受惩罚地重构的能力是一个巨大的好处，因为您始终可以验证功能通过在任何更改代码后运行测试。诀窍是不要过于关注您正在测试的工作单元或您如何构建测试需求以及单元测试何时真的是功能测试等。人们会为这些东西争论几个小时最后，现实情况是，您在编写代码时进行的任何测试都比不这样做要好。另一个公理是关于质量而不是数量 - 我见过 1000' 的代码库 s 的测试基本上没有意义，因为其余的测试并没有真正测试任何有用的东西或特定领域的任何东西，比如特定领域的业务规则等。我还看到了代码覆盖率为 30% 的代码库，但这些测试是相关的、有意义的并且非常棒，因为它们测试了编写代码的核心功能并表达了代码的使用方式。

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

Answer 24

我最近在我的工作场所经历了完全相同的经历，发现他们中的大多数人都知道理论上的好处，但必须专门向他们推销这些好处，所以这是我（成功地）使用的几点：

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

还有那个大...

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

Answer 25

几年前我发现了 TDD，并从那时起使用它编写了我所有的宠物项目。我估计 TDD 一个项目所花费的时间与牛仔一起完成它所花费的时间大致相同，但是我对最终产品的信心越来越大，以至于我不禁有一种成就感。

我还觉得它改进了我的设计风格（更加面向界面，以防我需要一起模拟事物），正如顶部的绿色帖子所写，它有助于“编码便秘”：当你不知道什么时写下，或者你面前有一项艰巨的任务，你可以写小。

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

Answer 26

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

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

每次从存储库更新时，花费数小时更新由于新功能而损坏的测试既不高效也不有趣。

Answer 27

如果您使用 NUnit，一个简单但有效的演示是在它们前面运行 NUnit 自己的测试套件。看到一个真正的测试套件给一个代码库一个锻炼值一千字......

Answer 28

单元测试对任何开发人员都无法想象的项目有很大帮助。它们允许您在签入之前运行单元测试套件并发现您是否破坏了某些东西。这大大减少了在等待其他人修复他们签入的错误时不得不坐下来玩弄拇指的情况，或者为了完成一些工作而恢复他们的更改的麻烦。它在重构方面也非常有价值，因此您可以确定重构后的代码通过了原始代码所做的所有测试。

Answer 29

使用单元测试套件，您可以对代码进行更改，同时保持其余功能不变。这是一个很大的优势。完成新功能的编码后，您是否使用单元测试套件和回归测试套件。

Answer 30

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

相反，功能测试是针对用户的：每当您添加功能测试时，您就是在测试用户将看到的东西。添加单元测试时，您只是让开发人员的生活更轻松。在这方面，这有点奢侈。

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

Answer 31

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

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

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

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

单元测试回归分析工具

Answer 32

我同意与大多数人相反的观点： 不编写单元测试也没关系， 尤其是原型繁重的编程（例如 AI）很难与单元测试结合起来。

Answer 33

单元测试的重点是使测试变得容易。它是自动化的。“进行测试”，你就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。

Answer 34

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

我建议在代码之前编写测试，添加新的测试/数据以发展主代码的功能！

Answer 35

作为一名物理专业的学生，​​我非常渴望真正证明我的代码可以按预期工作。您可以在逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试做出（尽可能接近）功能的经验证明。

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

Answer 36

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

在单元测试之前，我可以非常准确地预测编写代码需要多长时间，但不能预测我需要多少时间来调试它。

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

Answer 37

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

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

  use_ok( 'Foo' );
  

• 所有 POD（Plain Ol' Documentation）的格式是否正确？使用 Test::Pod 验证所有文件中所有 POD 格式的有效性。

你可能不认为这些是大事，其实也不是，但我可以保证你会抓到一些麻烦。当这些测试每小时运行一次，并且它捕捉到某人的过早提交时，你会让人说“嘿，这太酷了”。

Answer 38

就在今天，我不得不更改一个之前已经为其编写过单元测试的类。
测试本身写得很好，并且包含了我从未想过的测试场景。
幸运的是，所有测试都通过了，我的更改很快得到验证，并充满信心地投入到测试环境中。

Answer 39

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

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

Answer 40

你想说服谁？工程师还是经理？如果你想说服你的工程师同事，我认为你最好的办法是迎合他们制作高质量软件的愿望。有许多研究表明它可以发现错误，如果他们关心做得好，这对他们来说应该足够了。

如果您试图说服管理层，您很可能必须进行某种成本/收益推理，即未检测到的缺陷的成本大于编写测试的成本。一定要包括无形成本，例如失去客户信心等。

Answer 41

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

Answer 42

这是非常以.Net 为中心的，但是有人尝试过Pex吗？

在我尝试之前我非常怀疑 - 哇，多么好的表现。在我想“在我了解它实际上对我有什么好处之前，我不会被这个概念说服”。我只跑了一次就改变主意并说“我不在乎你怎么知道那里有致命异常的风险，但现在我知道我必须处理它”

也许这种行为的唯一缺点是它会标记所有内容并给您六个月的积压。但是，如果你有代码债务，你总是有代码债务，你只是不知道而已。告诉 PM 可能存在 20 万个故障点，而在您意识到几十万个故障点之前是一个令人讨厌的前景，这意味着首先解释这个概念至关重要。

Answer 43

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

Answer 44

单元测试适用于 QA 人员或您的经理，而不适用于您；所以这绝对不值得。

您应该专注于编写正确的代码（无论它是什么意思），而不是测试用例。让其他人担心这些。