test mutation-02-变异测试 mutate-test-kata入门介绍

拓展阅读

mutate-test-kata

使用变异测试来淘汰虚假单元测试

代码卡塔：使用变异测试提高单元测试质量的练习。

摘要

这是一组练习，将演示：

由于测试质量低，仅仅通过单元测试和高单元测试覆盖率数字可能会给人一种虚假的安全感。
如何使用变异测试和常见的测试异味（test smells）来识别问题点。
如何解决这些问题。

什么是代码卡塔？

代码卡塔是一种编程练习，通过实践帮助程序员磨练他们的技能。代码卡塔通常被设置为一系列单元测试，这些测试会失败。

你的任务是编写代码使它们通过。这个想法灵感来自于日本武术中的卡塔概念。

就像在武术中一样，你可以多次重复卡塔来改进解决方案。

请注意，这个卡塔有点不同 - 所有测试最初都会通过。

不用担心，上面提到的所有想法在这里仍然适用。

我们将改进测试，使它们失败，然后我们将修复代码使测试通过，但到那时它们将成为好的测试。

运行这个卡塔

要构建这个卡塔，你将需要：

Java 17 或更新版本
Maven 3.6.1 或更新版本
你选择的集成开发环境（IDE）

这个项目中有两个模块：

kata - 包含练习，包括下面描述的领域和测试类。你应该使用这个模块进行工作。
solutions - 包含卡塔练习的解决方案以及对测试异味的解释（参见下面的"单元测试异味"部分）。解决这个卡塔有多种方法，所以你的解决方案可能不会完全与这个模块中的相同，事实上，你可能会找到改进这里解决方案的方法。

这个卡塔的领域由两个类组成：Company（公司）和Employee（雇员）：

运行mtk.domain.CompanyTest类中的所有单元测试。它们应该都通过。使用Maven的输出或IDE测试运行器中的覆盖率报告功能检查测试覆盖率指标。覆盖率应该接近100%。好消息是：有测试，它们都通过，而且覆盖了所有业务逻辑。看起来软件准备好发布了！

不幸的是，这将是一个糟糕的主意，因为代码中充满了错误。为了证明这一点，只需查看mtk.CompanyRunner类，其中的main()方法包含一些简单的业务逻辑。运行mtk.CompanyRunner.main()并查看控制台输出。看起来正常吗？尽管有这么多的测试，为什么会有这么多的错误呢？

运行带有突变的单元测试。突变将通过PIT（一个变异测试工具）引入到你的代码中。

启用项目的pitest Maven配置文件。此配置文件绑定到Maven生命周期的测试阶段。
在kata模块中运行test任务（要在命令行中运行带有激活配置文件的命令，请执行mvn test -P pitest命令）。启用配置文件后，此任务将调用PIT框架首先在应用代码中引入更改，然后执行测试。
检查结果。结果以HTML格式写入到target/pit-reports/YYYYMMDDHHMI目录中的文件中。在浏览器中打开此文件 - 你应该会看到相当多的红色。这意味着一些代码突变设法幸存下来 - 没有被单元测试捕捉到。这意味着实际上我们的单元测试没有测试它们应该测试的内容。
修复测试异味。测试类中的每个测试都表现出一个或多个测试异味。逐个检查测试，修复异味并确保测试实际上执行了它应该执行的操作。为了帮助你，一些测试方法的注释明确说明了哪些异味存在。一旦去除异味，测试应该开始失败。这是一件好事，因为现在我们有了实际验证软件行为的测试。
修复业务逻辑，使测试通过。查看代码中的注释，它们可能会解释其预期行为（这并不意味着按照编写的方式行为符合预期）。
杀死所有突变体！以这种方式修复的测试应该能够捕捉到PIT引入的突变。当所有测试（和受测试的逻辑）都被修复时，不应该有突变能够幸存。因此，最终状态应该是通过测试和死亡突变。没有异味。

这个文档的其余部分提供了一些建议，如果你是单元测试的新手，这可能会很有用。

单元测试 - 必要但不足够...

...来在被测试的软件系统中建立信心。虽然我们的重点在单元测试上，但将它们放在更广泛的背景中会有所帮助。下表列出了常见类型的测试。

列的含义：

Category - 测试的类别

Purpose - 为什么需要这种类型的测试

Who - 在测试创建和验证测试结果中涉及的角色

Tools - 支持这种类型测试的示例工具

当转换为Markdown格式时，表格的样式如下：

markdown 复制代码

| 类别                  | 目的                                           | 参与者               | 工具          |
|-----------------------|-----------------------------------------------|----------------------|---------------|
| 单元                  | 在低层次（代码）验证行为单元，侧重于系统的小部分（例如，一个方法） | 开发者               | JUnit         |
| 验收                  | 验证特定场景下业务逻辑是否按规定实现              | 开发者，用户          | FitNesse      |
| 突变                  | 确保单元测试和验收测试的质量                    | 开发者               | PITest        |
| 集成                  | 检测系统模块之间的交互问题                      | 技术运维，开发者       |               |
| 用户验收              | 由用户认证整个系统是否按预期运行                  | 开发者，用户          |               |
| 生产镜像              | 在与生产环境相同的负载下测试系统                  | 技术运维             |               |
| 混沌工程              | 通过对基础设施（服务进程、网络、客户端等）进行故障注入来测试系统的弹性 | 技术运维             | Chaos Monkey  |
| 断点                  | 确定系统能够支持的最大负载                       | 技术运维             | The Grinder    |

单元测试最佳实践

以下是确保单元测试有效、易于维护和易于执行的一些建议实践：

自动化：不需要人为干预来确定结果。
专注：每个测试方法测试一个场景。
完整：测试边缘情况，尽量覆盖所有有意义的不同场景。
良好命名：测试方法的名称描述正在测试的场景。
快速：相关的测试在几秒钟内或更短时间内执行。
独立：没有外部依赖项，不依赖于其他测试。
测试行为，而不是实现。

单元测试异味

以下是测试可能存在问题的迹象 - 这可能是因为测试本身编写得不好，或者受测代码不友好于测试（这可能意味着这段代码结构不良）：

没有断言
不相关的断言
使用模拟（Mocks）
期望结果是通过计算而不是明确指定的
测试代码重用（即测试逻辑重用，测试工具类是好的）
测试数据重用
"闪烁"测试（具有非确定性行为的测试）
测试之间的相互依赖（例如，执行顺序）
运行时间长的测试
被@Ignore或注释掉的测试

这些异味经常一起出现。例如，共享测试数据可能导致测试的成功取决于执行顺序。

单元测试质量

我们如何衡量系统中单元测试的质量？一个广泛使用的度量是测试覆盖率。一些需要记住的事情：

测试覆盖率
- 由测试覆盖的代码行、方法、类的百分比
- 不保证覆盖的代码实际上被测试
- 确定绝对没有被测试的代码
因此，设置覆盖率目标并非完全没有意义，但是...
不要仅仅为了覆盖率而进行优化

我们如何确保测试实际上进行了测试？变异测试是确保单元测试的相关性的一种方式。

变异测试

变异测试是验证单元测试质量的一种方式。

它意味着在代码中引入变化并观察单元测试的行为。

假设在变异之前所有的测试都通过，那么一些单元测试将会开始失败（好的），或者所有测试都将继续通过（不好）。

后一种情况意味着单元测试实际上并未验证受测代码的结果：从所有意图上看，结果变得随机，但所有测试都通过。

测试驱动开发

采用测试驱动开发（TDD）将带来更好的测试、更好的接口、更少的不必要代码以及更自信和稳定的开发过程。

只需按照以下步骤：

编写一个测试
采用用户的视角："什么API会使我的工作最简单？"
思考小的增量
使测试通过
不惜一切代价：重复代码？可以！硬编码预期结果？可以！
重构
消除重复
为所有有意义的不同场景重复
收获好处
- 几乎所有代码都经过测试
- 你知道何时停止编码
- 用户友好的接口
- 结构良好的代码
- 恰到好处的抽象
- 恰到好处的代码
- 自信地进行开发！

听起来好像难以置信？

秘诀在于，TDD确实需要从实践者那里获得很多纪律，以便以微小的增量工作，刻苦地按照上述步骤进行，不走捷径。

缺乏纪律很可能最终导致通常的"质量"测试（和受测代码）。

参考资料

https://github.com/vmzakharov/mutate-test-kata