此为抛砖贴，希望能引出更好的见解。
你会怎么单元测试这样一个service层的类？
public class Service {
private BizOne bizOne;
private BizTwo bizTwo;
public boolean doBiz(Object param) {
Object resultOne = bizOne.getIt(param);
if (resultOne == null) {
return false;
}
return bizTwo.getIt(param) == null;
}
...
}
不管怎么测，对bizOne和bizTwo的调用都得mock掉，否则你的测试类可能会直接访问数据库或者依赖容器。所以你可能会这样写测试代码：
// do mocking
BizOne bizOne = expectBizOneNotReturnNull(param);
BizTwo bizTwo = expectBizTwoReturnNull(param);
// inject mocked objects
service.setBizOne(bizOne);
service.setBizTwo(bizTwo);
assertTrue(service.doBiz(param));
看起来不错，但有两个小问题：
1. Mock的bizOne, bizTwo对象需要再通过setter方法注入到service对象中。一种测试场景就得写一次setter注入，多种测试场景就得写多次了，这会比较繁琐，而且可能会让测试代码失去重点。
2. expectBizOneNotReturnNull, expectBizTwoReturnNull 跟业务逻辑无法直接对应。被测类背后的真实契约是“符合bizOne逻辑”且“符合bizTwo逻辑 => 返回true”，而不是“A为空，B不为空之类的”
何不改成这样：
//do mocking
expectBizOneValid(service, param);
expectBizTwoValid(service, param);
assertTrue(service.doBiz(param));
这里就不用再手工用setter拼装了，而且，契约感也很强：expectBizOneValid + expectBizTwoValid => assertTrue
你还顺便获得了一个好处：你会意识到，被测代码本身也应该增强契约感，应该这样改写：
public class Service {
private BizOne bizOne;
private BizTwo bizTwo;
public boolean doBiz(Object param) {
//用isBizOneValid()替代bizOne.getIt(param)!=null, 代码能更直接地反应业务逻辑，这也是《重构》这本书里极力推荐的作法
if (!isBizOneValid(param)) {
return false;
}
return isBizTwoValid(param);
}
//这里要用包可见性方法，因为测试类里要mock它
boolean isBizTwoValid(Object param) {
return bizTwo.getIt(param) == null;
}
boolean isBizOneValid(Object param) {
Object resultOne = bizOne.getIt(param);
return resultOne != null;
}
...
现在Service本身的实现也很像契约了。当然，你也可以看出副作用： 只mock Service类的部分方法，这需要mock框架支持； 另外，isBizTwoValid()这种私有契约要设成包可见性以方便被同一个包下的测试类mock（否则就得javaagent + 反射，很麻烦）
好处和坏处都有，看你的口味了。最后总结一下 －－关于“Mock Service这个类自己的方法，而不是Mock BizOne, BizTwo”这种做法
1.好处：
a.Mock别人就意味着要做一次组装，有点烦
b.Mock可以强迫被测类的内部接口更具契约感，测试类更具契约感
2.坏处
a.Mock框架需支持Partial Mock (推荐jmockit)
b.被Mock的内部方法要么设成包可见性（损失封装性），要么设成private并通过方式名反射来Mock（损失方法名的重构安全性）