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