彩票走势图

什么是单元测试？

单元测试是测试应用程序的各个单元或组件的实践，以验证每个单元是否正常工作。通常，unit（单元）应该是应用程序的一小部分 - 在Java中，它通常是单个类。请注意，并不是严格定义“unit”，开发人员需要决定每个测试的测试代码范围。

人们有时将“单元测试”一词与“集成测试”或“端到端测试”进行对比。不同之处在于，通常，单元测试是用于验证单个可测试单元的行为，而集成测试则验证多个组件的行为或整个应用程序的行为。就像我所说，构成“单元”的定义并没有严格定义，由你来决定每个测试的范围。

为什么选择单元测试？

单元测试是一种经过验证的技术，可确保软件质量，并带来很多好处。以下是选择单元测试的一些重要原因：

• 单元测试验证了您的每个软件不仅在今天可以正常运行，而且在将来也继续工作，为未来的发展奠定了坚实的基础。
• 单元测试在生产过程的早期阶段识别了缺陷，这减少了在开发周期的后期阶段修复它们的成本。
• 经过单元测试的代码通常更容易重构，因为可以快速重新运行测试以验证行为没有改变。
• 编写单元测试迫使开发人员考虑生产代码的设计如何使其适合于单元测试，并使开发人员从不同的角度看待他们的代码，鼓励他们在实现中考虑极端情况和错误条件。
• 在代码审查过程中包括单元测试可以揭示修改后的代码或新代码应该如何工作。此外，审核人员可以确认测试是否良好。

不幸的是，经常开发人员要么根本不编写单元测试，要么没有编写足够的测试，要么不维护它们。可以理解，毕竟单元测试有时候写起来很棘手，或者维护起来很费时。有时会遇到最后期限，感觉编写测试会让我们错过截止日期。但是，没有编写足够的单元测试或没有编写好的单元测试容易跳入一个陷入风险的陷阱。

因此，请考虑以下最佳实践建议，了解如何编写干净，可维护，自动化的测试，以最少的时间和精力为您提供单元测试的所有好处。

单元测试最佳实践

让我们看一下构建，运行和维护单元测试的一些最佳实践，以获得最佳结果。

单元测试应该值得信赖

如果代码被破坏，并且只有代码被破坏，测试才会失败。如果没有，我们无法相信测试结果告诉我们的是什么。

单元测试应该是可维护和可读的

当生产代码发生变化时，通常需要更新测试，并且可能还需要调试。所以它必须易于阅读和理解测试，不仅适用于编写它的人，也适用于其他开发人员。始终组织和命名您的测试，以提高清晰度和可读性。

单元测试应验证单个用例

好的测试验证一件事或者只验证一件事，这意味着他们通常会验证一个用例。遵循此最佳实践的测试更简单，更易理解，这有利于可维护性和调试。验证多个事物的测试很容易变得复杂且耗时。不要让这种情况发生。

另一个最佳实践是使用最少数量的断言。有些人建议每次测试只有一个断言（这可能有点过于严格限制了）; 我们的想法是专注于仅验证您正在测试的用例所需的内容。

单元测试应该是隔离的

测试应该可以在任何机器上以任何顺序运行，而不会相互影响。如果可能，测试应该不依赖于环境因素或全局/外部状态。具有这些依赖性的测试更难以运行并且通常不稳定，使得它们更难以调试和修复，并且最终花费的时间比它们节省的时间更多（参见上面的可靠信息）。

几年前Martin Fowler撰写了一篇关于代码的文章，描述了应用程序代码中的依赖用法，以及如何相应地设计测试。在他的文章中，“孤独”代码不依赖于其他单元（它更独立），而“社交”代码确实与其他组件交互。如果应用程序代码是单独的，那么测试很简单......但是对于正在测试的社交代码，您可以构建“单独”或“社交”测试。“社交测试”将依赖于实际依赖性以验证行为，而“孤立测试”将测试中的代码与依赖性隔离开来。您可以使用模拟来隔离测试中的代码，并为“社交”构建“单独”测试 码。我们将在下面看看如何做到这一点。

图1：社交与孤独测试。资料来源：Martin Fowler，2014年

一般来说，使用mock（模拟）作为依赖项使我们作为测试人员的生活更容易，因为我们可以为社会化代码生成“单独的测试”。对复杂代码的社交测试可能需要大量设置，并且可能违反被隔离和可重复的原则。但是由于模拟是在测试中创建和配置的，因此它是自包含的，我们可以更好地控制依赖项的行为。另外，我们可以测试更多代码路径。例如，我可以返回自定义值或从模拟中抛出异常，以覆盖边界或错误条件。

单元测试应该是自动化的

确保测试正在自动化过程中运行。这可以是每天，也可以是每小时，也可以是持续集成或交付流程。报告需要可供团队中的每个人访问和审核。作为一个团队，请讨论您关注的指标：代码覆盖率，修改后的代码覆盖率，正在运行的测试数量，性能等。

通过观察这些数字可以学到很多东西，而这些数字的巨大变化往往表明可以立即解决的回归问题。

使用良好的单元和集成测试混合

Michael Cohn的书“ 使用敏捷成功：使用Scrum进行软件开发”，  使用测试金字塔模型解决了这个问题（见下图中的插图）。这是描述测试资源理想分布的常用模型。这个想法是，当你进入金字塔时，测试通常构建起来更复杂，更脆弱，运行速度更慢，调试速度更慢。较低级别更加独立，更集成，更快速，更易于构建和调试。因此，自动化单元测试应该构成您的大部分测试。

单元测试应验证所有细节，边角情况和边界条件等。应更谨慎地使用组件，集成，UI和功能测试，以验证API或应用程序的整体行为。手动测试应该是整个金字塔结构的最小百分比，但仍然可用于发布验收和探索性测试。该模型为组织提供了高水平的自动化和测试覆盖率，因此他们可以扩展测试工作并将与构建，运行和维护测试相关的成本保持在最低水平。

单元测试应在有组织的测试实践中执行

为了在各个层面推动测试的成功，并使单元测试过程具有可扩展性和可持续性，您将需要一些额外的实践。首先，这意味着在编写应用程序代码时编写单元测试。一些组织在应用程序代码（测试驱动或行为驱动编程）之前编写测试。重要的是测试与应用程序代码齐头并进。甚至应该在代码审查过程中一起审查测试和应用程序代码。评论可以帮助您理解正在编写的代码（因为他们可以看到预期的行为）并改进测试！

编写测试以及代码不仅适用于新行为或计划更改，它对于错误修复也很重要。您修复的每个错误都应该有一个测试，以验证错误是否已修复。这可以确保错误在将来保持不变。

对失败的测试采用零容忍策略。如果您的团队忽略了测试结果，那么为什么要进行测试呢？测试失败应该表明真正的问题......所以在他们浪费QA的时间之前立即解决这些问题，或者更糟糕的是，他们进入已发布的产品。

解决故障所需的时间越长，这些故障最终会花费您的组织的时间和金钱就越多。因此，在重构期间运行测试，在提交代码之前运行测试，并且在测试通过之前不要将任务视为“完成”。

最后，保持这些测试。正如我之前所说，如果你在应用程序发生变化时没有及时更新这些测试，那么它们就会失去价值。特别是如果他们失败了，那么失败的测试每次失败都需要花费时间和金钱来进行调查。当代码更改时，根据需要重构测试。

正如您所看到的，最大化您在单元测试中投入的金钱和时间的回报需要在应用最佳实践方面进行一些投资。但最终，最后的奖励值得初步投资。

代码覆盖率如何？

通常，代码覆盖率是在自动化测试运行时执行多少生产代码的度量。通过运行一系列测试并查看代码覆盖率数据，您可以大致了解正在测试的应用程序的数量。

代码覆盖范围很多 - 最常见的是线覆盖和分支覆盖。大多数工具都专注于线路覆盖，它只是告诉您是否覆盖了特定线路。分支更精细，因为它告诉您是否覆盖了代码中的每条路径。

代码覆盖率是一个重要的指标，但请记住，增加它是达到目的的手段。它非常适合在测试中找到差距，但这并不是唯一需要关注的问题。注意不要花费太多精力来实现100％的覆盖率 - 它甚至可能不可行或不可行，而且测试的质量确实是重要的。话虽如此，为您的项目实现至少60％的覆盖率是一个很好的起点，80％或更多是一个很好的目标。显然，由您来决定该目标应该是什么。

如果您拥有自动化工具，不仅可以测量代码覆盖率，还可以跟踪测试覆盖的修改代码量，这也很有价值，因为这可以提供对是否正在编写足够的测试以及生产代码更改的可见性。

请参阅Parasoft报告和分析中心的示例代码覆盖率报告，如果您使用Parasoft Jtest进行单元测试，则可以浏览：

另外要记住的是，在编写新测试时，要注意单独关注行覆盖，因为单行代码可能导致多个代码路径，因此请确保测试验证这些代码路径。线路覆盖是一个有用的快速指示器，但它不是唯一要寻找的东西。

增加覆盖率的最明显方法是为更多代码路径添加更多测试，以及测试方法的更多用例。增加覆盖率的有效方法是使用参数化测试。对于Junit4，内置了Junit4参数化功能和第三方库，如JunitParams。Junit5具有内置参数化功能。

最后，如果您还没有跟踪测试覆盖率，我强烈建议您现在就开始。有很多工具可以提供帮助，比如Parasoft Jtest。首先测量您当前的覆盖率数字，然后设定应该在哪里的目标，首先解决重要的差距，然后从那里开始工作。

总结

尽管单元测试是一种用于确保软件质量的成熟技术，但它仍然被认为是开发人员的负担，许多团队仍然在努力解决这个问题。为了充分利用测试和自动化测试工具，测试必须值得信赖，可维护，可读，独立，并用于验证单个用例。自动化是使单元测试可行且可扩展的关键。

此外，软件团队需要练习良好的测试技术，例如编写和审查测试以及应用程序代码，维护测试以及确保立即跟踪和修复失败的测试。采用这些单元测试最佳实践可以快速提高单元测试结果。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或资源的朋友，请