作者
Phill Powell
Staff Writer
IBM Think
Ian Smalley
Staff Editor
IBM Think
什么是单元测试？
单元测试是一种用于评估软件的测试驱动开发 (TDD) 方法，专注于评估软件的单个组件或代码单元，即可能的最小增量。
单元测试涉及隔离单元，以便在将单元与应用程序的其他部分集成之前确认功能。
单元测试 框架 提供了短期和长期的优点。短期内，单元测试通过允许 自动化 测试 促进更快的开发过程。从长期来看，单元测试能够降低劳动力成本，因为在 软件开发生命周期 (SDLC) 后期需要进行的 调试工作会减少，而那时的调试成本往往要高得多。
需要较少调试的原因是单元测试支持增强的代码质量。单元测试鼓励提前和警惕地检测错误，所有这些都发生在开发过程的早期阶段。通过专注于单个单元，测试人员可以专注于“运行单元”，即正在评估的代码片段或代码行。
最终效果是构建了一个更强大的代码库，其中代码更改在软件测试期间被定义并安全地进行，从而取代了可能仍然存在的早期和过时的 旧版代码 。
在所有类型的测试中，单元测试可以被认为是“左移”规则最纯粹的例子。左移测试方法的目标是，根据从左到右顺序移动的设想项目时间表，将软件测试的某些部分转移到 SDLC 中的更早位置。
。因此，如果测试人员对源代码的最小部分进行操作，这就是在项目最基本的层面上工作，将其置于项目时间线的最左侧。 事实上，单元测试可以是左移的，在进行任何实际的软件工程之前就开始了。单元测试的一个方面是，它促使软件开发人员在早期设计阶段考虑潜在的单元问题，并在心理上解决这些问题。
行业时事通讯
辅以专家洞察分析的最新科技新闻
通过 Think 时事通讯，了解有关 AI、自动化、数据等方面最重要且最有趣的行业趋势。请参阅 IBM 隐私声明 。
谢谢！您已订阅。
您的订阅将以英语提供。您会在每份时事通讯中找到一个取消订阅链接。您可以在此管理您的订阅或取消订阅。更多相关信息，请参阅我们的《IBM 隐私声明》。
单元测试与其他测试类型
在软件测试领域，有几种类型的测试似乎共享某些属性和功能。
例如，很容易理解为什么单元测试和简单测试之间偶尔会出现混淆。从字面上看，这两个术语似乎有相似的含义，我们知道单元测试专注于代码的简单部分。但尽管单元测试局限于测试代码的基本部分，简单测试——尽管名称如此——可能相当广泛和复杂。
简单测试也可用于各种目的，例如集成测试（查看组件如何协同工作的情况）。简单测试甚至可用于进行端到端测试（以衡量总体系统性能）。两者的主要区别在于测试环境不同。单元测试力求在隔离状态下测试代码，而简单测试可能不一定如此。
幸运的是，其他测试类型的模糊性要小得多。例如，验收测试分析整个软件系统及其在满足业务期望和用户需求方面的有效性。验收测试发生在 SDLC 的后期，紧接着回归测试（确保代码更改不会导致功能错误）之后和系统部署之前。
通常，单元测试与其他测试类型之间最显著的区别在于它们在 SDLC 中的位置。单元测试需要在生命周期的早期发生。另一个关键区别涉及代码是否被单独检查。
应用程序开发
开启旅程：云端企业应用程序开发
在本视频中，Peter Haumer 博士通过演示不同的组件和实践（包括 IBM Z Open Editor、IBM Wazi 和 Zowe），探讨了混合云环境中现代企业应用程序的开发现状。
深入了解云应用程序开发
单元测试的五个步骤
单元测试有五个广泛认可的步骤，必须按顺序处理。
1. 确定单元
在这里，测试人员选择要分析的单元测试代码，这可能是一个函数、类或方法。
2. 选择方法
下一步是选择要实施的测试类型，无论是手动测试还是通过众多可能的框架之一进行的自动化单元测试。
3. 建立测试环境
在实际进行单元测试之前，测试人员需要确保测试环境满足执行测试的所有要求，包括测试数据、依赖项和模拟对象。此时，使用集成开发环境 (IDE) 至关重要。
IDE 是一款软件应用程序，可以被视为一种多用途瑞士军刀，包含编写、构建、测试和调试代码所需的所有工具。IDE 促进单元测试的创建和执行。
4. 创建和使用测试用例
测试人员选择一个单元测试框架并编写要使用的测试用例。在开发和执行测试期间，编译器将用编程语言编写的测试转换为可执行代码。在进行测试用例后，测试人员确认测试结果。
5. 调试和解决问题
最后，还剩下一个后续步骤。如果任何测试用例失败，测试人员需要调试代码并确认其根本原因。然后，测试人员应该修复问题。之后，测试人员需要再次运行单元测试，以确保代码中的所有错误均已修复。
单元测试工具
当开发人员编写和运行测试时，他们有各种测试工具可供选择，具体取决于特定需求：
Jest： 用于测试 JavaScript 和 React 组件的 JavaScript 框架。Jest 的属性之一是它报告代码覆盖率的有用方式，包括正在评估的总代码的百分比。另一个属性是它专注于提供“零配置”测试体验，最大限度地减少设置时间，开发人员可以尽快开始编写测试。Jest 被认为简单易用，深受开发人员欢迎。
JUnit：JUnit 是用于测试 Java 组件的 Java 框架。使用 JUnit 的优势包括更好的代码组织、更彻底的错误检测和更强大的代码修复。除此之外，JUnit 被认为有助于提高软件质量和简化测试流程。尽管 JUnit 主要用于单元测试，但它也可以用于（整个系统的）集成测试和功能测试。
Mocha：Mocha 是一个用于测试 JavaScript 代码的开源框架。Mocha 基于“测试”结构和“测试套件”（用于建立和分组测试的组织工具）实现测试自动化和测试执行。Mocha 的框架被认为具有多功能性，可以根据不同的测试需求进行调整。Mocha 的另一个优势是全面的测试结果报告，因此开发人员可以检测测试失败并开始调试工作。
NUnit: NUnit 是另一个开源测试框架，旨在与 .NET 平台及其相关语言（如 C#、VB.NET 和 F#）配合使用。它提供基于测试属性的单元测试，这些属性建立测试方法，并在测试前后与设置代码和清理代码一起工作。NUnit 提供各种断言方法，帮助验证预期的代码行为，并使用 NUnit 控制台运行器进行测试的批量执行。
Pytest：Pytest 是一个用于编写和执行 Python 测试的框架。它的多功能性体现在其在单元测试、集成测试、端到端测试和功能测试中的使用。它的主要优点是对测试参数化提供的内置支持，允许您使用不同的配置或输入运行相同的测试，而无需复制测试代码。它还支持轻松模拟和修补（暂时用模拟对象替换真实对象、函数或方法），包括为测试目的创建模拟对象。
xUnit：xUnit 是另一个流行的开源单元测试框架，通常用于与 C# 编程语言相关的开发活动。xUnit 专为单元测试目的而设计，在为测试组件提供隔离的代码运行环境方面表现出色。xUnit 还因其直观且易于掌握的语法而备受推崇，这简化了测试创建。此外，它还可以与其他测试工具很好地集成，以实现无缝的工作流。
单元测试最佳实践
正如这些战略所说明的那样，单元测试代表了一种深入参与和动手的测试方法。
尽可能多地测试代码
重要的是要看到尽可能多地测试和评估代码的关键部分。虽然测试 100% 的代码并不总是可行的，但您仍然应该争取一个相对较高的测试覆盖率，例如 70-80% 的范围。测试的频率也应该增加，以支持持续测试。
使用模拟和桩
模拟和桩对于正确隔离测试环境至关重要。模拟最好被描述为测试替身，允许测试人员在更大的隔离环境中检查对象的可能行为。桩允许测试人员看到隔离的测试替身将如何与外部依赖项（如组件）交互。
使用 CI/CD 管道
使用持续整合/持续交付 (CI/CD) 管道是测试过程的关键，因为它们可以自动化测试功能。通过运行 CI/CD 管道，每当有任何代码更改时，都会运行自动化的单元测试。
考虑极端用途
边缘情况反映了在单元的边界或操作参数处发生的极端使用模式。正因为如此，边缘情况有助于识别可能不会立即显现的错误。这些错误的示例包括越界数组访问，即用于逐项列出的索引超出该索引的允许值。在这些情况下，通常需要重构代码——在保持其现有功能的同时重新构建代码。
AI 对单元测试的影响
与所有计算一样，人工智能 (AI)为单元测试带来了强大的新速度和其他优点。以下是一些示例，说明 AI 现在如何彻底改变单元测试：
更快的测试编写：AI 可以比人类更快地创建整套单元测试，帮助开发团队按计划完成所需的测试，而不会对产品发布周期产生负面影响。
更好的测试覆盖：AI 在检测人类测试人员可能忽略的边缘情况方面表现出色。然而，AI 最令人惊叹的技巧可能是其生成“自我修复”测试的能力，这些测试可以从代码更改模式中学习，从而使测试随时间保持相关性。
高级测试分析：AI 解锁了运行复杂测试的能力，例如预测性测试失败分析，它使用历史数据和代码模式来确定迫在眉睫的测试失败。同样，AI 可以进行根本原因分析，找出测试失败的根本原因。
持续反馈： 随着 AI 推动单元测试向前发展，与开发环境以及开发运维和 CI/CD 管道的强大整合变得更加容易。通过整合，测试人员可以获得持续的反馈并实现更快的开发周期。