问题描述
假如有如下方法public void publicMethod(){ if(condition1) privateMethod1(); else privateMethod2(); }private void privateMethod1(){ ...... privateMethod3();}private void privateMethod2(){ ...... privateMethod4();}在上述私有方法中，可能会依赖很多的外部类，并且可能会有多重分支，这样的话以publicMothod做为入口，并且mock私有方法中依赖的所有的外部类行为来进行测试，将会非常麻烦，并且分支都是级数级的。请问这种情况大家都是如何进行单元测试的？
解决方案
单元测试的重点是“单元”，所以测试对象不应过大，而应该尽量小而且职责应该单一。如果测试对象过大或者过于复杂，则说明设计存在问题，需要重构，这正是单元测试的宗旨和目标————促进重构改善设计。这里private里面调用了多个外部类，应该尽量简化，同时每个调用的外部类方法也应该是单独进行测试的。另外，如果你重构之后还是需要测试这个private方法，可以把它改成protected，然后单元测试类继承这个类，就可以进行测试了，因为子类是可以访问父类的protected方法的。向LZ推荐一本单元测试的书————JUnit.Recipes(JUnit菜谱)。书中讲了N多中单元测试中的技巧和解决方案，非常实用，建议一览，会有恍然大悟之感。书里讲的那些技巧非常巧妙，有些你可能在实践中曾经自己发现过并引以为豪，但是看了这本书，你会发现它里面已经罗列出来了，我就曾有这种经历。下面这是网上转来的，说的还是有一定道理的：如何对private方法进行单元测试问：如何对私有方法进行单元测试？答：重点在于，你不应该有任何方法是从一开始设计出来就是private的，因为你的每段程序都应该在单元测试的驱动之下产生，而测试是不可能驱动出 来一个private方法的。那么private方法从哪里来？只能从重构而来。所以答案是：private方法是不需要测试的，因为它是重构的产物，而 重构是不改变程序可观察之行为的。既然行为不改变，测试自然也不需要有任何改变，所以不需要针对private方法建立任何新的测试。问：但是，如果private方法确实出现问题了怎么办？如果确实希望用测试来弄清一个private方法里面到底发生了什么，该怎么办？答：如果一个private方法复杂到你不能一眼看清它，那它就太复杂了，你应该把它重构成为一个独立的class，然后针对这个class来建立单元测试。
解决方案二：
1. 对私有方法的测试, 有两种方法是. 第一: 把权限级别改为包级别. 第二: 通过反射. 我一般用第一种方式. 2. 关于测试依赖的问题. 如果累A方法a(也就是A.a)依赖一个外部组件的B的方b(也就是B.b), 通常我会把对B.b的调用抽取为一个A的一个方法c: private void c (){ B.b(); }然后把c mock掉.
解决方案三：
PowerMock 可以包级别 也行