使用Spock解决单元测试开发中的痛点
如果在（if/else）分支很多的复杂场景下，编写单元测试代码的成本会变得非常高，正常的业务代码可能只有几十行，但为了测试这个功能覆盖大部分的分支场景，编写的测试代码可能远不止几十行。
之前有遇到过某个功能上线很久一直都很正常，没有出现过问题，但后来有个调用请求的数据不一样，走到了代码中一个不常用的逻辑分支时，出现了Bug。当时写这段代码的同学也认为只有很小几率才能走到这个分支，尽管当时写了单元测试，但因为时间比较紧张，分支又多，就漏掉了这个分支的测试。
尽管使用JUnit的@Parametered参数化注解或者DataProvider方式可以解决多数据分支问题，但不够直观，而且如果其中某一次分支测试Case出错了，它的报错信息也不够详尽。
这就需要一种编写测试用例高效、可读性强、占用工时少、维护成本低的测试框架。首先不能让业务人员排斥编写单元测试，更不能让工程师觉得写单元测试是在浪费时间。而且使用JUnit做测试工作量不算小。据初步统计，采用JUnit的话，它的测试代码行和业务代码行能到3:1。如果采用Spock作为测试框架的话，它的比例可缩减到1:1，能够大大提高编写测试用例的效率。
下面借用《编程珠玑》中一个计算税金的例子。
public double calc(double income) {
BigDecimal tax;
BigDecimal salary = BigDecimal.valueOf(income);
if (income <= 0) {
return 0;
}
if (income > 0 && income <= 3000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.03);
tax = salary.multiply(taxLevel);
} else if (income > 3000 && income <= 12000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.1);
BigDecimal base = BigDecimal.valueOf(210);
tax = salary.multiply(taxLevel).subtract(base);
} else if (income > 12000 && income <= 25000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.2);
BigDecimal base = BigDecimal.valueOf(1410);
tax = salary.multiply(taxLevel).subtract(base);
} else if (income > 25000 && income <= 35000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.25);
BigDecimal base = BigDecimal.valueOf(2660);
tax = salary.multiply(taxLevel).subtract(base);
} else if (income > 35000 && income <= 55000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.3);
BigDecimal base = BigDecimal.valueOf(4410);
tax = salary.multiply(taxLevel).subtract(base);
} else if (income > 55000 && income <= 80000) {
BigDecimal taxLevel = BigDecimal.valueOf(0.35);
BigDecimal base = BigDecimal.valueOf(7160);
tax = salary.multiply(taxLevel).subtract(base);
} else {
BigDecimal taxLevel = BigDecimal.valueOf(0.45);
BigDecimal base = BigDecimal.valueOf(15160);
tax = salary.multiply(taxLevel).subtract(base);
}
return tax.setScale(2, BigDecimal.ROUND_HALF_UP).doubleValue();
}
能够看到上面的代码中有大量的if-else语句，Spock提供了where标签，可以让我们通过表格的方式来测试多种分支。
@Unroll
def "个税计算,收入:#income, 个税:#result"() {
expect: "when + then 的组合"
CalculateTaxUtils.calc(income) == result
where: "表格方式测试不同的分支逻辑"
income || result
-1 || 0
0 || 0
2999 || 89.97
3000 || 90.0
3001 || 90.1
11999 || 989.9
12000 || 990.0
12001 || 990.2
24999 || 3589.8
25000 || 3590.0
25001 || 3590.25
34999 || 6089.75
35000 || 6090.0
35001 || 6090.3
54999 || 12089.7
55000 || 12090
55001 || 12090.35
79999 || 20839.65
80000 || 20840.0
80001 || 20840.45
}
上图中左边使用Spock写的单元测试代码，语法简洁，表格方式测试覆盖分支场景更加直观，开发效率高，更适合敏捷开发。
单元测试代码的可读性和后期维护
我们微服务场景很多时候需要依赖其他接口返回的结果，才能验证自己的代码逻辑。Mock工具是必不可少的。但jMock、Mockito的语法比较繁琐，再加上单元测试代码不像业务代码那么直观，又不能完全按照业务流程的思路写单元测试，这就让不少同学对单元测试代码可读性不够重视，最终导致测试代码难以阅读，维护起来更是难上加难。甚至很多同学自己写的单元测试，过几天再看也一样觉得“云里雾里”的。也有改了原来的代码逻辑导致单元测试执行失败的；或者新增了分支逻辑，单元测试没有覆盖到的；最终随着业务的快速迭代单元测试代码越来越难以维护。
Spock提供多种语义标签，如：given、when、then、expect、where、with、and等，从行为上规范了单元测试代码，每一种标签对应一种语义，让单元测试代码结构具有层次感，功能模块划分更加清晰，也便于后期的维护。
Spock自带Mock功能，使用上简单方便（Spock也支持扩展第三方Mock框架，比如PowerMock）。我们可以再看一个样例，对于如下的代码逻辑进行单元测试：
public StudentVO getStudentById(int id) {
List<StudentDTO> students = studentDao.getStudentInfo();
StudentDTO studentDTO = students.stream().filter(u -> u.getId() == id).findFirst().orElse(null);
StudentVO studentVO = new StudentVO();
if (studentDTO == null) {
return studentVO;
}
studentVO.setId(studentDTO.getId());
studentVO.setName(studentDTO.getName());
studentVO.setSex(studentDTO.getSex());
studentVO.setAge(studentDTO.getAge());
// 邮编
if ("上海".equals(studentDTO.getProvince())) {
studentVO.setAbbreviation("沪");
studentVO.setPostCode("200000");
}
if ("北京".equals(studentDTO.getProvince())) {
studentVO.setAbbreviation("京");
studentVO.setPostCode("100000");
}
return studentVO;
}
比较明显，左边的JUnit单元测试代码冗余，缺少结构层次，可读性差，随着后续的迭代，势必会导致代码的堆积，维护成本会变得越来越高。右边的单元测试代码Spock会强制要求使用given、when、then这样的语义标签（至少一个），否则编译不通过，这样就能保证代码更加规范，结构模块化，边界范围清晰，可读性强，便于扩展和维护。而且使用了自然语言描述测试步骤，让非技术人员也能看懂测试代码（given表示输入条件，when触发动作，then验证输出结果）。
Spock自带的Mock语法也非常简单：dao.getStudentInfo() >> [student1, student2]。
两个右箭头>>表示模拟getStudentInfo接口的返回结果，再加上使用的Groovy语言，可以直接使用[]中括号表示返回的是List类型。
单元测试不仅仅是为了统计代码覆盖率，更重要的是验证业务代码的健壮性、业务逻辑的严谨性以及设计的合理性
在项目初期阶段，可能为了追赶进度而没有时间写单元测试，或者这个时期写的单元测试只是为了达到覆盖率的要求（比如为了满足新增代码行或者分支覆盖率统计要求）。
很多工程师写的单元测试基本都是采用Java这种强类型语言编写，各种底层接口的Mock写起来不仅繁琐而且耗时。这时的单元测试代码可能就写得比较粗糙，有粒度过大的，也有缺少单元测试结果验证的。这样的单元测试对代码的质量帮助不大，更多是为了测试而测试。最后时间没少花，可效果却没有达到。
针对有效测试用例方面，我们测试基础组件组开发了一些检测工具（作为抓手），比如去扫描大家写的单元测试，检测单元测试的断言有效性等。另外在结果校验方面，Spock表现也是十分优异的。我们可以来看接下来的场景：void方法，没有返回结果，如何写测试这段代码的逻辑是否正确？
如何确保单元测试代码是否执行到了for循环里面的语句，循环里面的打折计算又是否正确呢？
public void calculatePrice(OrderVO order){
BigDecimal amount = BigDecimal.ZERO;
for (SkuVO sku : order.getSkus()) {
Integer skuId = sku.getSkuId();
BigDecimal skuPrice = sku.getSkuPrice();
BigDecimal discount = BigDecimal.valueOf(discountDao.getDiscount(skuId));
BigDecimal price = skuPrice * discount;
amount = amount.add(price);
}
order.setAmount(amount.setScale(2, BigDecimal.ROUND_HALF_DOWN));
}
如果用Spock写的话，就会方便很多，如下图所示：
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
