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

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

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

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

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

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

比如我们有一个

private int getUserAge(String userId) 的方法，为了测试，在test中可以有如下结构。

//调用指定对象的指定方法。用java的反射机制实现。
private Object invokeMethod(String methodName, Class<?>[] parameterClasses, Object object,
                                Object[] parameters)

//转发调用。
private int invokeGetUserAge(String userId){
    调用invokeMethod,做适当的类型转换。
}

//真正的test方法，调用invokeGetUserAge。
public void testGetUserAge()




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

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

举个例子，
public Object f(Object input){
  根据input计算出s1,s2,s3,s4,flag
  if(flag){
    a=g(s1,s2);
    return a;
  }else{
    b=g(s3,s4);
    return b;
  }
}

public void f1(){
调用g.
}

private Object g(Object o1,Object o2){
}


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方法。

测试私有方法不是个好主意. 更不要滥用反射,破坏对protected/private的约定.

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

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

举个例子，
public Object f(Object input){
  根据input计算出s1,s2,s3,s4,flag
  if(flag){
    a=g(s1,s2);
    return a;
  }else{
    b=g(s3,s4);
    return b;
  }
}

public void f1(){
调用g.
}

private Object g(Object o1,Object o2){
}


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方法。

不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类

只针对接口测试

这种情况与其用反射区牺牲重构方面的利益，不如干脆把private变成protected或者default。

反射有时还有用的，
对于private的内部变量只有class内部用，不对外的。
但是UT一个方法是要改变private变量的值来实现UT覆盖就需要反射了。

反正具体情况具体对待 哈哈。

第一，正常使用者怎么改变它的值；第二，改变它的值对使用者有什么影响。
你只要考虑这两个问题，那么很显然private变量的值必定是能通过某个外在行为来改变、并从而影响某个外在行为的，因此一定是能通过外在行为来测试的。
如果某个private变量的值不能通过外在行为来改变，那它的使用者就无法改变它；如果它的值改变不会影响外在行为，那它的使用者就不在乎它。如果它的使用者不能改变它或者不在乎它，你为什么要测试它？

这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。

这个很有道理。不要滥用反射进行这种测试。如果利用反射进行对private方法进行测试。那么本质上就是忽略了private方法作用了。