简化Java单元测试数据

用EasyModeling简化Java单元测试

EasyModeling 是我在2021年圣诞假期期间开发的一个 Java 注解处理器，采用 Apache-2.0 开源协议。它可以帮助 Java 单元测试的编写者快速构造用于测试的数据模型实例，简化 Java 项目在单元测试中准备测试数据的工作，在提高编写效率的同时，使单元测试更加整洁易读。经过一年的维护，EasyModeling 已经在几个 Thoughtworks 内部的项目上得到了应用，并迭代发布了几个版本。

单元测试中的数据准备的困难

在企业级应用软件开发项目中编写测试代码时，针对特定的测试场景，我们需要准备相应的测试数据，以验证被测组件在给定输入下的行为。在使用 Java 语言的项目中，这些准备测试数据的代码体现为创建各种“数据模型类”的实例。这里的数据模型类，可以包括聚合模型（Aggregation Model）、数据传递模型（DTO）、值对象（VO）以及存储模型（Persist Model）等等。无论是对服务组件的测试，还是对数据模型本身的测试，我们都无可避免地需要构建这些数据模型类的实例。

在项目的起初阶段，准备数据的工作是简单的，我们只需要调用数据模型类的构造方法，传入适当的参数来创建实例即可。单元测试代码的规模不会太大，也尚且清晰易读。

但是随着产品开发工作的展开，一方面，项目中使用的这些数据模型会变得越来越复杂；另一方面，测试场景也会变得越来越多。经验上，在经过几个版本迭代的企业级应用 Java 代码中，我们通常不难找出一些拥有十几个、甚至几十个成员变量的数据模型类，并且它们之间还存在着复杂的相互持有、嵌套、继承的关系。这些数据模型类往往都是项目中的核心组件，故而也成为单元测试需要重点关注的组件。相应地，在涉及这些数据模型的单元测试中，为准备测试数据而编写的初始化数据模型类的代码量也会越来越大、越来越复杂。

这些冗杂繁复的数据初始化代码会影响单元测试本身的代码质量，造成单元测试编写成本高、易读性差、易维护性低等问题。而单元测试的质量又与生产代码的质量息息相关。例如，单元测试的编写成本过高，会使开发者越来越倾向于仅在已有测试基础上做修改，而不是为每个场景创建单独的测试，造成单个测试的职责过多；甚至使开发者放弃单元测试，降低了团队对产品质量的信心。又比如，单元测试的易读性差，导致单元测试无法承担起“测试即文档（tests as documentation）”的职责。而单元测试的易维护性低，则导致了代码很难被重构，从而单元测试不仅没有为重构提供信心，反而变成重构的桎梏。

具体来说，这些初始化数据的代码会引起三个方面的问题：

• 对测试场景的描述不清晰
• 构建测试数据的代码重复
• 初始化数据模型代码的膨胀

我们可以从下面的例子中略窥端倪。你是否在你的项目中见过这样的单元测试？