单元测试｜ Unit Testing

单元测试｜ Unit Testing
- 相关术语
- 有关单元测试的问题吗？

测试单个软件单元或组件以验证其功能的实践。

有关单元测试的问题吗？

基础知识和重要性

什么是单元测试？

单元测试是测试应用程序的最小可测试部分（通常是函数或方法）的做法，与系统的其余部分隔离。这些测试由开发人员编写和执行，以确保代码库的特定部分按预期执行。在单元测试中，每个单元都使用存根和模拟进行隔离测试，以模拟不属于测试一部分的依赖模块的行为。这可以在早期阶段发现问题，从而更容易解决问题。一个好的单元测试应该是：

专注：它应该测试一个功能或方法并做好它。
快速：它应该快速运行，以免减慢开发或 CI/CD 管道的速度。
独立：它不应该依赖于外部系统或其他测试的状态。
可重复：在给定相同的输入的情况下，每次运行都应该产生相同的结果。
自我验证：它应该清楚地显示测试是否通过或失败，而不需要手动分析。单元测试通常使用与其测试的代码相同的编程语言编写，并在开发过程中频繁运行。当单元测试失败时，表明存在需要解决的问题才能继续。流行的单元测试框架包括用于 Java 的 JUnit、用于.NET 的 NUnit、用于 Python 的 unittest 和用于 JavaScript 的 Jest。这些工具提供了一种编写和运行单元测试的结构化方法，通常具有模拟和断言功能。

  // Example of a simple unit test in TypeScript
  import { add } from './math';
  test('adds 1 + 2 to equal 3', () => {
    expect(add(1, 2)).toBe(3);
  });

为什么单元测试很重要？

单元测试至关重要，因为它确保软件的各个组件单独按预期工作。通过单独测试这些组件，开发人员可以：

**尽早检测并修复bugs**在开发过程中，这通常比稍后在更高的测试级别或部署后找到它们更具成本效益。
重构代码充满信心，知道测试将揭示更改是否会破坏现有功能。
记录代码 ，因为单元测试可以作为如何使用 API 的示例。
设计更好的代码结构 ，因为可测试的代码通常会带来更加模块化和灵活的设计。
促进整合 ，因为独立测试的单元更有可能无缝集成。
加快开发进程 ，因为自动化测试可以快速且频繁地运行。
改进代码覆盖率 ，因为彻底的单元测试可以测试代码中的所有路径和条件。单元测试通常由开发人员编写和运行，通常使用持续集成系统来确保代码的持续运行状况。当单元测试失败时，这表明代码库中的某些内容以未预期或未考虑的方式发生了更改，从而促使立即调查和修复。这种即时反馈循环对于维护强大的代码库至关重要，尤其是在敏捷和快节奏的开发环境中。
**尽早检测并修复bugs**在开发过程中，这通常比稍后在更高的测试级别或部署后找到它们更具成本效益。
重构代码充满信心，知道测试将揭示更改是否会破坏现有功能。
记录代码 ，因为单元测试可以作为如何使用 API 的示例。
设计更好的代码结构 ，因为可测试的代码通常会带来更加模块化和灵活的设计。
促进整合 ，因为独立测试的单元更有可能无缝集成。
加快开发进程 ，因为自动化测试可以快速且频繁地运行。
改进代码覆盖率 ，因为彻底的单元测试可以测试代码中的所有路径和条件。

单元测试有什么好处？

单元测试提供了多项可提高软件质量和可维护性的优势：

隔离：隔离测试各个组件，确保每个部件独立正常运行。
回归检测：当更改破坏现有功能时，快速识别回归，以便立即修复。
设计改进：鼓励更好的设计和架构，因为组件必须可以单独测试，通常会产生更加模块化的代码。
重构信心：提供一个安全网，促进自信的重构，知道测试将捕获任何引入的错误。
文档：充当系统的动态文档。开发人员可以查看测试来了解该单元的预期行为。
调试效率：通过精确定位测试单元内缺陷的确切位置来简化调试。
开发速度：可以通过尽早发现错误来加快开发过程，减少调试和手动测试所花费的时间。
代码质量：通常会带来更高的代码质量和更少的错误，因为开发人员在编写代码时会考虑可测试性和边缘情况。
成本降低：通过在开发周期的早期发现错误来降低修复错误的成本，通常修复这些错误的成本更便宜。通过将单元测试集成到开发工作流程中，团队可以实现更可靠、可维护和健壮的代码库，最终导致更成功的软件项目。

单元测试和其他类型的测试有什么区别？

单元测试是测试应用程序的最小可测试部分（通常是函数或方法）的做法，与系统的其余部分隔离。其他类型的测试（例如集成测试、系统测试和验收测试）的范围和重点有所不同：

集成测试 评估不同单元或组件之间的交互，以确保它们按预期协同工作。它比单元测试更高一个级别，并识别集成组件之间的接口和交互中的问题。
系统测试 考虑整个系统的行为，旨在验证完整的集成软件产品是否满足指定的要求。这是更高级别的测试，包含完整的集成软件，用于评估系统是否符合其指定的要求。
验收测试 执行以确定系统是否准备好发布。它通常由最终用户或客户完成，以根据业务需求验证功能和性能。验收测试以用户为导向，重点关注系统是否按照用户的要求进行操作。单元测试的独特之处在于它专注于软件的最小部分，而其他类型的测试则针对系统更全面的方面，从组件如何协同工作到系统在现实场景中的执行方式。了解这些差异有助于测试自动化工程师在适当的级别上设计和执行测试，以确保软件产品的健壮性和可靠性。

单元测试如何融入软件开发生命周期？

单元测试是软件开发生命周期 (SDLC) 不可或缺的一部分，通常嵌入在编码阶段中。当开发人员编写代码时，他们同时创建单元测试来验证每个功能或模块的正确性。这种做法确保新代码不会破坏现有功能并从一开始就遵守指定的要求。在敏捷方法中，单元测试更为重要，因为它支持持续集成 (CI) 和 持续交付 (CD)。开发人员经常将他们的更改合并到共享存储库中，在其中运行自动构建和测试。单元测试是第一道防线，可以在问题传播到后期阶段或生产之前尽早发现问题。单元测试也在重构中发挥作用。在改进或优化代码时，单元测试提供了一个安全网，确认行为保持一致。这允许自信的代码更改并鼓励更干净、更可维护的代码库。在维护期间，单元测试有助于识别更改的影响，确保bug修复或功能添加不会引入新问题。它们充当代码预期行为的动态文档。总之，单元测试贯穿整个 SDLC，从最初的开发到维护，支持软件项目的质量、敏捷性和可靠性。它使开发人员能够更高效地工作，降低引入错误的风险，并有助于在软件的生命周期内保持较高的代码质量。

单元测试技术

单元测试中使用了哪些不同的技术？

单元测试中的不同技术包括：

黑盒测试：专注于单元的功能，而不考虑其内部代码结构。测试基于规范和要求。
白盒测试：涉及查看正在测试的代码的结构。测试基于代码语句、分支、路径和条件的覆盖范围。
灰盒测试：黑盒和白盒测试的组合，测试人员对应用程序内部工作的了解有限。
积极测试：确保设备在给定有效输入时按预期运行。
负面测试：确保设备正常处理无效输入或条件。
边界测试：专注于输入域的边缘条件，测试分区之间的边界。
等价划分：将输入数据划分为可以以类似方式测试的等效分区，从而减少所需的测试总数。
基于状态的测试：检查单元在经历一系列状态更改时的行为。
突变测试：修改代码的某些部分以检查现有单元测试是否可以检测到更改；它有助于评估测试的质量。
基于属性的测试：根据指定的属性生成随机输入数据，并检查设备在各种输入中是否表现正常。
错误猜测：依靠测试人员的经验来猜测单元中最可能发生错误的区域，并专门为那些容易出错的区域编写测试。每种技术可以独立使用或组合使用，以确保单元测试的全面覆盖和稳健性。
黑盒测试：专注于单元的功能，而不考虑其内部代码结构。测试基于规范和要求。
白盒测试：涉及查看正在测试的代码的结构。测试基于代码语句、分支、路径和条件的覆盖范围。
灰盒测试：黑盒和白盒测试的组合，测试人员对应用程序内部工作的了解有限。
积极测试：确保设备在给定有效输入时按预期运行。
负面测试：确保设备正常处理无效输入或条件。
边界测试：专注于输入域的边缘条件，测试分区之间的边界。
等价划分：将输入数据划分为可以以类似方式测试的等效分区，从而减少所需的测试总数。
基于状态的测试：检查单元在经历一系列状态更改时的行为。
突变测试：修改代码的某些部分以检查现有单元测试是否可以检测到更改；它有助于评估测试的质量。
基于属性的测试：根据指定的属性生成随机输入数据，并检查设备在各种输入中是否表现正常。
错误猜测：依靠测试人员的经验来猜测单元中最可能发生错误的区域，并专门针对那些容易出错的区域编写测试。

什么是测试驱动开发？

测试驱动开发 (TDD) 是一个软件开发过程，依赖于非常短的开发周期的重复。开发人员首先编写一个自动化的测试用例来定义所需的改进或新功能，然后生成最少数量的代码以通过该测试，最后重构新代码以达到可接受的标准。 TDD 主要是一种设计理念，强调在代码库中编写相应功能之前编写测试。该过程从开发测试用例的最小功能单元开始，通常是在函数或方法级别。这些测试最初预计会失败，这是 TDD 红绿重构周期的一个关键方面：

红色：编写反映所需更改或新功能的失败测试。
绿色：实现使测试通过的代码。
重构：清理代码，同时确保所有测试仍然通过。 TDD 鼓励简单的设计并激发对软件功能的信心。它还确保代码从一开始就经过测试，因为测试是在需要通过测试的代码之前编写的。

  function add(a, b) {
    return a + b;
  }
  // Test case for the 'add' function
  test('adds 1 + 2 to equal 3', () => {
    expect(add(1, 2)).toBe(3);
  });

在上面的示例中，add 函数的测试是在函数本身实现之前编写的。创建函数并且测试通过后，可以重构代码以改进其结构或效率，并通过测试确保函数的行为保持正确。

什么是行为驱动开发？

行为驱动开发 (BDD) 是一种敏捷软件开发流程，鼓励软件项目中的开发人员、QA 以及非技术或业务参与者之间的协作。它的重点是通过与利益相关者的讨论来清楚地了解所需的软件行为。 BDD 通过以非程序员可以阅读的自然语言编写测试用例来扩展测试驱动开发 (TDD)。 BDD 中的测试基于用户故事，并使用名为 gherkin 的语言进行描述。 gherkin 使用一组特殊关键字来为可执行规范提供结构和含义。最重要的关键词是：

功能：系统的一个值得注意的方面。
场景：特定行为或用例。
给定：场景开始时的初始上下文。
何时：触发场景的事件。
然后：给定上下文和事件的预期结果。以下是 BDD 测试用例的示例：

  Feature: User login
  Scenario: Existing user successfully logs in
    Given the user has navigated to the login page
    When they enter their correct username and password
    Then they should be granted access to their dashboard

BDD Cucumber、SpecFlow 或 Behat 等工具解析这些规范并将其作为测试执行。结果表明软件是否按预期运行。 BDD 有助于确保所有利益相关者对需求有共同的理解，并且软件满足这些需求。它弥合了技术和非技术团队成员之间的差距，促进更好的沟通和协作。

如何编写好的单元测试？

编写良好的单元测试需要遵守几个关键原则：

隔离：确保测试仅涵盖一个工作单元，避免依赖于其他单元。使用模拟或存根来模拟外部依赖关系。
可读性：编写易于理解的测试。对描述预期结果和测试条件的测试函数使用清晰的命名约定。
自信：专注于每个测试单元的单一行为或方面。应避免针对不同行为的多个断言。
可重复性：无论运行环境如何，测试都应产生相同的结果。避免依赖外部状态或数据。
自动化性：确保测试可以自动运行，无需手动步骤。
速度：保持快速测试以维持快速反馈循环。
稳健性：测试不应因单元实现的微小变化而中断。针对单元的公共 API 进行测试并避免测试内部结构。
维护：编写易于维护的测试。必要时重构测试以使其与代码库保持同步。以下是使用 Jest 在 TypeScript 中进行简单单元测试的示例：

  import { add } from './math';
  test('adds 1 + 2 to equal 3', () => {
    expect(add(1, 2)).toBe(3);
  });

请记住定期重构测试，并通过代码更改使它们保持最新。当测试失败时，在更正代码或测试之前分析失败，确保测试继续达到验证正确性的目的。

模拟对象在单元测试中的作用是什么？

模拟对象通过模拟真实对象的行为，在 单元测试 中发挥着至关重要的作用。它们用于创建一个受控环境，其中测试仅关注工作单元，没有外部依赖项，例如数据库、网络调用或其他服务。通过使用模拟对象，您可以：

隔离正在测试的代码单元，确保故障是由于单元本身的问题造成的，而不是与外部系统或依赖项的交互造成的。
指定与模拟对象的预期交互，允许您验证代码单元与其依赖项的行为是否正确。
控制通过模拟各种场景（包括错误条件、边缘情况或可能难以用实际依赖项重现的不常见情况）来测试环境。
提高测试性能因为与模拟对象的交互通常比与真实依赖项的交互更快，从而导致更快的测试执行时间。模拟对象通常是使用模拟框架创建的，它允许您轻松设置预期的行为和断言。以下是使用 TypeScript 模拟框架的示例：

  import { it, describe } from 'mocha';
  import { expect } from 'chai';
  import { mock, instance, when, verify } from 'ts-mockito';
  describe('UserService', () => {
    it('should create a new user', () => {
      const mockRepository = mock(UserRepository);
      const userService = new UserService(instance(mockRepository));
      const user = new User('test@example.com', 'password123');
      when(mockRepository.save(user)).thenReturn(Promise.resolve(user));
      await userService.create(user);
      verify(mockRepository.save(user)).once();
      expect(await mockRepository.save(user)).to.equal(user);
    });
  });

在此示例中，UserRepository 被模拟为专注于测试 UserService.create 方法，而不实际访问数据库。模拟可确保测试保持快速、可靠，并具有可预测的结果。

隔离正在测试的代码单元，确保故障是由于单元本身的问题造成的，而不是与外部系统或依赖项的交互造成的。
指定与模拟对象的预期交互，允许您验证代码单元与其依赖项的行为是否正确。
控制通过模拟各种场景（包括错误条件、边缘情况或可能难以用实际依赖项重现的不常见情况）来测试环境。
提高测试性能因为与模拟对象的交互通常比与真实依赖项的交互更快，从而导致更快的测试执行时间。

单元测试工具

有哪些流行的单元测试工具？

流行的单元测试工具因编程语言和开发环境而异。以下是一些广泛使用的选项：

JUnit：Java 开发人员的主要工具，提供注释和断言来简化测试。
NUnit ：与 JUnit 类似，但对于.NET 框架，它支持并行测试并拥有强大的社区。
TestNG ：另一个基于Java的工具，它提供更灵活的测试配置并支持数据驱动测试。
PHPUnit：PHP 的首选，它可以轻松与 CI 工具集成并支持数据库测试。
RSpec：Ruby 的行为驱动开发（BDD）框架，以其可读的语法而闻名。
MSTest ：微软的测试框架，与Visual Studio集成，方便.NET开发人员。
xUnit.net：.NET 的开源工具，支持理论测试和干净的执行模型。
pytest：一个功能强大的Python工具，语法简单，可通过插件扩展。
Jest ：在 JavaScript 世界中流行，特别是对于 React 应用程序，它提供快照测试。
Mocha：另一个JavaScript框架，它很灵活并且支持异步测试。
QUnit：专为 jQuery 设计，对于在任何环境中测试 JavaScript 都很有用。
Google Test：对于 C++ 开发人员来说，它是跨平台的，并且支持模拟对象等高级功能。每个工具都提供独特的功能，例如**代码覆盖率分析**、测试发现和与开发环境集成。选择正确的工具通常取决于项目的具体需求和开发团队的偏好。

如何选择合适的单元测试工具？

选择正确的单元测试工具需要评估几个因素，以确保它符合您的项目需求：

语言支持：确保该工具支持您的项目中使用的编程语言。
集成：寻找与您的开发环境和 CI/CD 管道无缝集成的工具。
性能：考虑测试的执行速度，因为它会影响开发人员的反馈循环。
可用性：具有用户友好界面和清晰文档的工具可以减少学习曲线并提高采用率。
功能：评估该工具是否提供必要的功能，例如测试覆盖率分析、测试用例分组和并行测试执行。
社区和支持：强大的社区和可用的支持对于故障排除和保持工具保持最新状态非常宝贵。
成本：根据您的预算评估该工具的成本，包括许可证和潜在的培训。
可扩展性：添加自定义功能或与其他工具集成的能力对于复杂的项目至关重要。
维护：考虑工具的更新频率以及代码库更改时更新测试的难易程度。根据这些标准评估工具，并考虑在完全投入之前进行小规模试验，以确保其满足项目的特定要求。

一个好的单元测试工具有哪些特点？

一个好的单元测试工具应该具有以下功能：

易于集成：它应该可以轻松地与开发环境和构建流程集成。
支持多种语言和框架：与所使用的语言和框架的兼容性。
测试用例 的隔离：能够模拟或消除外部依赖项以确保测试被隔离。
测试运行者 ：内置或兼容的测试运行程序，可以执行测试并报告结果。
断言库：用于验证测试结果的一套全面的断言。
测试覆盖率分析：测量和报告代码覆盖率的工具，以识别代码库中未经测试的部分。
性能和可扩展性：即使测试数量增加，也能有效执行测试。
并行测试执行 ：支持并行运行测试以加快进程。
自动测试发现：自动检测新的和现有的测试，以确保所有测试都得到执行。
持续集成 (CI) 兼容性：与 CI/CD 管道无缝集成以进行自动化测试。
调试功能：帮助诊断和修复失败测试的功能。
重构支持：如果行为保持不变，测试不应因重构代码而中断。
文档和社区支持：全面的文档和强大的故障排除和支持社区。
可扩展性：能够根据需要使用插件或附加框架来扩展工具。
许可和成本：考虑与该工具相关的许可条款和成本。选择具有这些功能的单元测试工具将有助于制定稳健且高效的测试自动化策略。

如何使用单元测试工具？

使用单元测试工具通常涉及以下步骤：

设置您的测试环境：安装单元测试工具并将其配置为与您的开发环境配合使用。
创建测试用例：编写专注于代码小单元的测试方法。使用断言来定义预期结果。

    function testAddition() {
      assertEquals(2 + 2, 4);
    }

安排、执行和断言 (AAA) 模式：使用环境搭建 (Arrange)、调用 (Act) 和验证 (Assert) 构建测试。

    // Arrange
    let calculator = new Calculator();
    // Act
    let result = calculator.add(2, 2);
    // Assert
    assertEquals(result, 4);

运行测试：使用工具的测试运行者执行测试。这通常可以通过命令行或在 IDE 中完成。
查看测试结果：分析工具提供的输出以查看哪些测试通过或失败。
重构并重复：如果测试失败，重构代码并再次运行测试。继续此过程，直到所有测试都通过。
与构建集成：通过将单元测试与构建过程集成来自动化单元测试，确保它们定期运行。
监控代码覆盖率：使用该工具的代码覆盖率功能来确保您的测试覆盖了代码库的很大一部分。请记住隔离工作单元，使用模拟对象或框架模拟依赖关系，并保持测试的独立性和可重复性。定期审查和重构测试，以保持其有效和可维护。
设置您的测试环境：安装单元测试工具并将其配置为与您的开发环境配合使用。
创建测试用例：编写专注于代码小单元的测试方法。使用断言来定义预期结果。

    function testAddition() {
      assertEquals(2 + 2, 4);
    }

安排、执行和断言 (AAA) 模式：使用环境搭建 (Arrange)、调用 (Act) 和验证 (Assert) 构建测试。

    // Arrange
    let calculator = new Calculator();
    // Act
    let result = calculator.add(2, 2);
    // Assert
    assertEquals(result, 4);

最佳实践

单元测试的最佳实践是什么？

单元测试的最佳实践包括：

写出清晰的、描述性的测试名称：您的测试名称应该记录您的测试正在做什么。例如，testIsEmptyListReturnedWhenNoElementsAdded() 比 testList() 提供更多信息。
保持测试独立：每个测试应独立于其他测试运行。避免测试之间共享状态，以防止可能导致片状测试的相互依赖性。
每次测试测试一个概念：专注于单元的单一行为或方面。这使得在测试失败时更容易识别出什么问题。
使用 Arrange-Act-Assert (AAA) 模式：使用环境搭建 (Arrange)、调用被测行为 (Act) 和断言 (Assert) 构建测试。
断言预期结果：确保您的测试检查设备的行为是否符合预期。使用有意义的断言，而不是像 assertNotNull() 这样的通用断言。
测试边界条件：包括对边缘情况和边界条件的测试，以捕获潜在的相差一错误和其他与边界相关的bugs。
保持测试快速：单元测试应该快速执行，以鼓励频繁的测试运行。
重构测试：对测试代码应用与生产代码相同的质量标准。重构测试以保持它们的干净和可维护。
使用代码覆盖率工具：以高代码覆盖率为目标，但不要盲目地以 100% 为目标。重点测试关键路径和复杂逻辑。
避免测试实现细节：测试单元的公共接口。测试实施可能会导致脆弱的测试，任何重构都会破坏测试。
处理预期的异常：如果一个单元应该在某些条件下抛出异常，请编写一个测试来断言抛出了异常。
明智地使用模拟对象：模拟依赖项来隔离被测单元，但不要过度使用模拟，因为它们可以隐藏问题并创建紧密耦合的测试。请记住，单元测试的目标是创建一个可靠且可维护的测试套件，为您的设备的行为提供信心。
写出清晰的、描述性的测试名称：您的测试名称应该记录您的测试正在做什么。例如，testIsEmptyListReturnedWhenNoElementsAdded() 比 testList() 提供更多信息。
保持测试独立：每个测试应独立于其他测试运行。避免测试之间共享状态，以防止可能导致片状测试的相互依赖性。
每次测试测试一个概念：专注于单元的单一行为或方面。这使得在测试失败时更容易识别出什么问题。
使用 Arrange-Act-Assert (AAA) 模式：使用环境搭建 (Arrange)、调用被测行为 (Act) 和断言 (Assert) 构建测试。
断言预期结果：确保您的测试检查设备的行为是否符合预期。使用有意义的断言，而不是像 assertNotNull() 这样的通用断言。
测试边界条件：包括对边缘情况和边界条件的测试，以捕获潜在的相差一错误和其他与边界相关的bugs。
保持测试快速：单元测试应该快速执行，以鼓励频繁的测试运行。
重构测试：对测试代码应用与生产代码相同的质量标准。重构测试以保持它们的干净和可维护。
使用代码覆盖率工具：瞄准高代码覆盖率但不要盲目瞄准 100%。重点测试关键路径和复杂逻辑。
避免测试实现细节：测试单元的公共接口。测试实施可能会导致脆弱的测试，任何重构都会破坏测试。
处理预期的异常：如果一个单元应该在某些条件下抛出异常，请编写一个测试来断言抛出了异常。
明智地使用模拟对象：模拟依赖项来隔离被测单元，但不要过度使用模拟，因为它们可以隐藏问题并创建紧密耦合的测试。

您应该多久运行一次单元测试？

单元测试应该尽可能频繁地运行，最好是每次对代码库进行更改时运行。这通常是通过持续集成（CI）系统来实现的，该系统在每次提交或推送到版本控制存储库时自动运行测试。经常运行单元测试有助于：

捕捉回归立即。
验证代码更改并确保它们不会破坏现有功能。
促进重构 ，因为测试的即时反馈可以指导开发人员。
加快开发进程 ，因为问题可以尽早发现并解决。实际上，这意味着为单元测试设置自动触发器：
每次提交：确保新代码与现有代码库良好集成。
合并分支之前 ：帮助维护主开发分支的稳定性。
作为拉取请求审查的一部分：防止将缺陷引入代码库。
按计划：捕获基于事件的触发器可能错过的问题，例如夜间构建。在 测试驱动开发 (TDD) 环境中，单元测试运行得更加频繁，因为它们是红绿重构周期的一部分：

编写失败的单元测试（红色）。
编写最少的代码以通过测试（绿色）。
重构代码（并再次运行测试）。通过将单元测试集成到开发工作流程中并利用自动化，您可以确保它们达到提供有关代码库运行状况的快速可靠反馈的目的。

捕捉回归立即。
验证代码更改并确保它们不会破坏现有功能。
促进重构 ，因为测试的即时反馈可以指导开发人员。
加快开发进程 ，因为问题可以尽早发现并解决。
每次提交：确保新代码与现有代码库良好集成。
合并分支之前 ：帮助维护主开发分支的稳定性。
作为拉取请求审查的一部分：防止将缺陷引入代码库。
按计划：捕获基于事件的触发器可能错过的问题，例如夜间构建。

编写失败的单元测试（红色）。
编写最少的代码以通过测试（绿色）。
重构代码（并再次运行测试）。

如何维护单元测试？

维护单元测试对于确保它们随着代码库的发展保持有效和相关性至关重要。以下是一些策略：

重构测试更新代码时。保持测试干净且可读，以使维护更容易。
删除过时的测试不再适用于代码库的当前状态。
保持测试隔离以避免在单个功能更改时可能破坏多个测试的依赖关系。
使用版本控制跟踪测试中的更改以及代码更改。
定期运行测试 ，最好通过持续集成，尽早发现问题。
修复bugs之前更新测试以确保他们捕获错误并验证修复。
记录测试意图必要时使用清晰的命名约定和注释。
避免测试实施细节 ;关注行为以减少重构代码时测试更改的需要。
审查测试在代码审查期间确保它们遵循最佳实践并且是最新的。
**监控测试覆盖率**确保新代码得到测试并识别冗余或缺失的测试。
参数化测试用一个测试用例覆盖一系列输入，使它们更容易扩展和维护。通过遵循这些准则，您可以在软件项目的整个生命周期中保持单元测试的稳健性、相关性和价值。
重构测试更新代码时。保持测试干净且可读，以使维护更容易。
删除过时的测试不再适用于代码库的当前状态。
保持测试隔离以避免在单个功能更改时可能破坏多个测试的依赖关系。
使用版本控制跟踪测试中的更改以及代码更改。
定期运行测试 ，最好通过持续集成，尽早发现问题。
修复bugs之前更新测试以确保他们捕获错误并验证修复。
记录测试意图必要时使用清晰的命名约定和注释。
避免测试实施细节 ;关注行为以减少重构代码时测试更改的需要。
审查测试在代码审查期间确保它们遵循最佳实践并且是最新的。
**监控测试覆盖率**确保新代码得到测试并识别冗余或缺失的测试。
参数化测试用一个测试用例覆盖一系列输入，使它们更容易扩展和维护。

当单元测试失败时你应该做什么？

当单元测试失败时，立即调查原因。请按照下列步骤操作：

**查看测试用例**以确保其设计正确并正在测试其应有的功能。
再次运行测试检查它是否是由于不确定行为或外部依赖性而导致的不稳定测试。
检查失败消息并通过堆栈跟踪寻找线索。
调试测试单步执行代码并确定其与预期行为的偏差。
检查最近的更改使用版本控制历史记录可能影响测试的代码库。
隔离问题如有必要，可以编写额外的测试来查明问题。
修复代码导致测试失败的原因，而不是测试本身，除非测试有缺陷。
重构代码如果修复增加了复杂性或重复逻辑，请确保所有测试仍然通过。
**运行完整的测试套件**确认更改没有破坏其他任何内容。
提交修复和测试到版本控制系统。
记录问题以及解决方案（如果这是一个反复出现的问题或可以使团队受益）。请记住，失败的单元测试是一个有价值的信号，表明代码中存在需要注意的问题。将其视为改进代码库和防止未来问题的机会。
**查看测试用例**以确保其设计正确并正在测试其应有的功能。
再次运行测试检查它是否是由于不确定行为或外部依赖性而导致的不稳定测试。
检查失败消息并通过堆栈跟踪寻找线索。
调试测试单步执行代码并确定其与预期行为的偏差。
检查最近的更改使用版本控制历史记录可能影响测试的代码库。
隔离问题如有必要，可以编写额外的测试来查明问题。
修复代码导致测试失败的原因，而不是测试本身，除非测试有缺陷。
重构代码如果修复增加了复杂性或重复逻辑，请确保所有测试仍然通过。
**运行完整的测试套件**确认更改没有破坏其他任何内容。
提交修复和测试到版本控制系统。
记录问题以及解决方案（如果这是一个反复出现的问题或可以使团队受益）。

单元测试 ｜ Unit Testing

相关术语