简化Java单元测试数据 _Java

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

文章插图
单元测试中的数据准备的困难
在企业级应用软件开发项目中编写测试代码时，针对特定的测试场景，我们需要准备相应的测试数据，以验证被测组件在给定输入下的行为。在使用 Java 语言的项目中，这些准备测试数据的代码体现为创建各种“数据模型类”的实例。这里的数据模型类，可以包括聚合模型（Aggregation Model）、数据传递模型（DTO）、值对象（VO）以及存储模型（Persist Model）等等。无论是对服务组件的测试，还是对数据模型本身的测试，我们都无可避免地需要构建这些数据模型类的实例。
在项目的起初阶段，准备数据的工作是简单的，我们只需要调用数据模型类的构造方法，传入适当的参数来创建实例即可。单元测试代码的规模不会太大，也尚且清晰易读。
但是随着产品开发工作的展开，一方面，项目中使用的这些数据模型会变得越来越复杂；另一方面，测试场景也会变得越来越多。经验上，在经过几个版本迭代的企业级应用 Java 代码中，我们通常不难找出一些拥有十几个、甚至几十个成员变量的数据模型类，并且它们之间还存在着复杂的相互持有、嵌套、继承的关系。这些数据模型类往往都是项目中的核心组件，故而也成为单元测试需要重点关注的组件。相应地，在涉及这些数据模型的单元测试中，为准备测试数据而编写的初始化数据模型类的代码量也会越来越大、越来越复杂。
这些冗杂繁复的数据初始化代码会影响单元测试本身的代码质量，造成单元测试编写成本高、易读性差、易维护性低等问题。而单元测试的质量又与生产代码的质量息息相关。例如，单元测试的编写成本过高，会使开发者越来越倾向于仅在已有测试基础上做修改，而不是为每个场景创建单独的测试，造成单个测试的职责过多；甚至使开发者放弃单元测试，降低了团队对产品质量的信心。又比如，单元测试的易读性差，导致单元测试无法承担起“测试即文档（tests as documentation）”的职责。而单元测试的易维护性低，则导致了代码很难被重构，从而单元测试不仅没有为重构提供信心，反而变成重构的桎梏。
具体来说，这些初始化数据的代码会引起三个方面的问题：

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

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

文章插图
图片
这是一段典型的使用JUnit测试框架的单元测试代码。在这段单元测试代码中，被测对象是 leaveCalculator 组件的 annualLeave 方法。我们首先创建一位员工，如（a）处；然后将创建好的员工对象传入 annualLeave 方法，为其计算出应得的年假数额，如（2）处；最后断言他应该享有20天年假，如（3）处。为了简化讨论，我们暂且假设此处 annualLeave 方法的业务规则是：员工应得的年假数额只与这位员工加入公司的时间（date of joining）相关，即在代码中 (1) 处初始化的日期。
我们来详细分析这段测试代码中存在的坏味道、以及其潜在的问题。
对测试场景的描述不清晰
如前文所述，我们假设这段单元测试代码的目的是验证“入职超过5年的员工应该享有20天年假”这个业务规则。那么显然，其中只有 (1), (2), (3) 这三处是与当前测试场景相关的，它们共同构成了对上述业务规则的描述。而在 (1) 处之前传入 Employee 类构造方法的那些参数都是与当前测试场景无关的。遗憾的是，这些与测试场景无关的代码却占据了这个代码片段中的绝大部分代码行。
在实际项目中，我们会见到很多这样的单元测试，它们往往需要用几十行的代码来准备复杂的测试数据，需要初始化数个数据模型类的对象，以支持对被测组件的调用，然而这些代码中真正在描述测试场景的，却只有其中区区几行、甚至一两行。这不仅增加了测试的篇幅，还会导致阅读者无法快速聚焦在有意义的初始化条件上。就像我们在这个例子中看到的，描述测试场景的代码行（1）处混杂在大量初始化测试数据的代码行之中，造成了单元测试对测试场景的描述不聚焦。这使单元测试的阅读者很难从这段测试代码中一目了然地理解测试的意图，更遑论以测试为文档来理解业务规则。而在测试失败时，也无法快速从测试场景的数据构造出发去定位问题。