单元测试顾名思义就是对单元进行测试，这里的单元就是方法。但是我们在类的设计中会设计方法的访问限定符，以此来更好的做到高内聚，低耦合。如果只是对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()
mock1234 写道
zhang_xzhi_xjtu 写道
在用反射做UT时，注意，使用的是getDeclaredMethod方法而不是getMethod，同时注意使用method.setAccessible(true)来使方法可以被访问。在实现的时候，最好有一个方法的转调，以减少代码重构对test的影响（这样只有一个地方hard code）。
比如我们有一个
private int getUserAge(String userId) 的方法，为了测试......
UT还private？更进一步地说，UT还纠结于单元测试？
如果你真的做UT，你在动手写代码之前就有关于用户行为（这里的用户不仅仅指最终用户，如果你是发布一组工具那么你的用户就是其它开发组中的程序员）的设计了，你可以将这种设计写为测试程序（而不是满足在可以随便忽悠着解释的文档），然后才开始开发。如果编译不通过，就让它编译通过；如果针对数据输入输出的断言不通过，就让断言通过！
你做UT时还纠结于private，甚至纠结于单元测试，咄咄怪事。（因为单元测试工具只是一个驱动测试开始执行的工具，而你要的是针对UT的对象而不是什么代码函数单元啊）。
更进一步说，好的测试是对重构提供支持的。你纠结于那些“单元”，还能重构吗？使用你的所谓单元测试代码维系垃圾代码，当作餐桌上的主菜，是不是本末倒置了？
我给你提供一个测试的“原则”作为参考。对于纯粹功能性的开发，我在写测试时保持大致1个半小时的开发时间（因为之前需要10～30分钟编写测试代码的时间），这就是我写测试的原则。
每当重构了，当然要回归运行那些测试代码。因此这些测试时为了支持重构这种高度灵活性的东西而准备的。
怎么可能像你那样，先写完了实现代码，然后才钻到垃圾堆底层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方法。