开篇
好久不发技术博客,今年要捡起来,新年第一篇就从单测的一个小点讲起
背景
作为要秃头的程序猿,我们每天要写非常多的单测代码,但是我们的单测目标更多时候是可以公开调用的Service层代码或是 Controller层代码,如果我们想测试Service层中我们悄悄写的一些 private方法,就有难度了.
如果一个项目是按一定规范开发的,测试代码一般和业务源码在不同包中,导致private方法无法在测试包中进行测试.这里我们就讲一个折中的办法,来测试这些藏在角落里的私有方法.
Start
首先我们写一个可测试的简单用例
package com.example.demo.design.impl;
import com.google.common.annotations.VisibleForTesting;
import lombok.extern.slf4j.Slf4j;
/**
* ID生成器
*
* @author ：Lingyun
* @date ：2020-02-17 17:46
*/
@Slf4j
public class RandomIdGenerator {
private String generate() {
return "我是private";
}
}
改造:第一步
我们知道私有方法在类外是肯定无法访问的,这时候杠精可能要来了,反射可以啊.
emmm,这种方案我们不考虑,为了测试我们去写一套反射实在是一件性价比很低的事情.既然private 方法不能在类外访问,那我们只能对实现做一点小的改动,比如把private 换成 protected.
protected String generate() {
return "我是private";
}
改造:第二步
我们变更了方法的作用域,但是这样操作是有风险的,通常private方法中我们并不会写参数和业务的前置和后置的校验,更多时候private方法都是代码的封装和抽象,我们修改了作用域,其他开发小伙伴在不知情的情况下贸然使用,可能会出各种问题.
在这里我们可以借助Guava中提供的一个注解来标明private方法的这次作用域变更的用途@VisibleForTesting,这个注解并不会实际改变方法的作用域,只是起到注释的作用,来告诉其他小伙伴调用此方法的风险
@VisibleForTesting
protected String generate() {
return "我是private";
}
改造:第三步
这时候如果你以为这个方法就可以测试了,那你天真了,尽管generate()方法的作用域已经修改为protected,但是因为protected的只能包内调用的特性,我们在测试路径写的测试方法依然不能正常调用到改方法,比如这样:
接下来的一点改动就是本篇文章的精华所在了,下面是RandomIdGenerator类的包路径
package com.example.demo.design.impl;
然后我们在测试路径下创建一个相同路径下的测试类 比如这样:
是不是很神奇,明明测试类和RandomIdGenerator类不在相同的路径下但是他们的 package 确是一样的,这时候我们再看测试方法中的generate()调用也不再报错了.
我们执行以下测试方法,看是否能正常执行
程序可以正常执行,并打印了日志
End
写这篇的目的是帮助大家可以用较简单和较低的成本来测试private方法,网上也有一些测试私有方法的文章,但是大多都是使用反射来实现的,这种方案每次都要去写一套反射代码,实用性并不高.至于方法的作用域的变更,只要标识明确清楚,对代码的影响是可控的.
