Service层的单元测试：毋宁Mock别人，不如Mock自己

Service层的单元测试：与其Mock别人，不如Mock自己
此为抛砖贴，希望能引出更好的见解。

你会怎么单元测试这样一个service层的类？

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（损失方法名的重构安全性）

查看更多 下一篇