使用反射提高单元测试的质量

首先，单元测试以及单元测试覆盖率只是一个工具，很烂的代码一样可以有全套的单元测试和很高的单元测试覆盖率（这里只指代码覆盖率，不涉及分支覆盖等）。其次，单元测试和覆盖率是有用的，尤其是在我们想把一件事情搞好的时候。

单元测试顾名思义就是对单元进行测试，这里的单元就是方法。但是我们在类的设计中会设计方法的访问限定符，以此来更好的做到高内聚，低耦合。如果只是对public的方法做测试，那么为了验证一些private方法的正确性，我们就需要以public方法为入口，构造复杂的测试上下文，如此，增大开发测试的负担。那么，对不公开的方法如何测试呢。

1采用java独特的包访问权限，这样的话，productcode和testcode可以放在不同的目录，但是可以有相同的包名。这样的缺点是test影响了productcode的设计。

2采用反射，采用反射可以访问productcode的private方法，这样，test和product就完全隔离开了。这样的缺点是test中对方法名要进行hardcode，不利于重构。但是权衡利弊，这个方法还是可行的。

在用反射做UT时，注意，使用的是getDeclaredMethod方法而不是getMethod，同时注意使用method.setAccessible(true)来使方法可以被访问。在实现的时候，最好有一个方法的转调，以减少代码重构对test的影响（这样只有一个地方hardcode）。

比如我们有一个

privateintgetUserAge(StringuserId)的方法，为了测试，在test中可以有如下结构。

//调用指定对象的指定方法。用java的反射机制实现。

privateObjectinvokeMethod(StringmethodName,Class<?>[]parameterClasses,Objectobject,

Object[]parameters)

//转发调用。

privateintinvokeGetUserAge(StringuserId){

调用invokeMethod,做适当的类型转换。

}

//真正的test方法，调用invokeGetUserAge。

publicvoidtestGetUserAge()

你说的这些我都是同意的，如果条件允许的话，我当然也是这么做，事实上，TDD的开发精髓就是测试驱动设计。

问题是我现在面临的场景中，业务逻辑很复杂，于是，为了方法的内聚性，一个public的方法往往需要调用拆分出去多个private方法，这是，如果坚持一套完整的测试的话，那么测试环境的搭建将变得复杂，或者说关注点不集中，因为测试的分支是成指数级别增长的，而为了系统的稳定性，我们需要覆盖掉所有的分支。我选择用反射来测试这些private方法可以分离测试的关注点。当然，这个对重构是有不好的影响的，权衡利弊，我只能采取一些措施降低这种影响，但是还是要保全一个test的完整性和专注性。

举个例子，

publicObjectf(Objectinput){

根据input计算出s1,s2,s3,s4,flag

if(flag){

a=g(s1,s2);

returna;

}else{

b=g(s3,s4);

returnb;

}

}

publicvoidf1(){

调用g.

}

privateObjectg(Objecto1,Objecto2){

}

flag有2种状态。

假设g方法的参数o1,o2各有3种状态。

如果采用先test后code的方法，为了完整的测试f的功能，那么我们需要控制input来生成所有的2*3*3=18个test才能完全覆盖到所有的分支。当然，也可以控制input生成flag为true的9种情况，以及1个flag为false的情况。

但是我觉得这样的测试关注点不够集中，我的思路是，可以先为f写两个test，来覆盖flag的两个分支，然后coding，保证f的两个分支都被测试到，即g都被调用过，至于g自己的方法约定，应该属于g自己的事情，可以用反射来测试。

我们在考虑一下如果f,f1都要调用g方法的情况，那么我们有必要为测试f,f1都建立g的9种状态吗？如果还有更多的f2,f3,...fn呢？

传统的test是一种黑盒测试，而用反射是白盒测试。我认为程序员是可以利用关于实现的知识进行测试的。利用反射，虽然一方面增加了重构的难度，但是，可以提高测试的关注点，同时，白盒测试也有利于重构出被多个public方法调用的private方法。