前言
最近因工作需要不得不对单元测试中的Mockito2和Powermock框架的一些新特性进行研究:比如Mockito2和Powermock可以伪造静态方法、final类甚至是构造函数的调用,但是研究一段后发现,这些功能其实在小编本来就很熟悉的Jmockit框架中就能实现,而且不用像mockito一样需要特殊的语法和额外的样板代码,看似掌握了一些所谓“高大上”的用法,实际对工作来说没有任何收益。因此今天这篇文章不会讲什么单测框架的高级特性,反而,我们来聊一聊指导我们进行单元测试的一些基本准则。
mock还是不mock?
为什么我们需要mock来进行单元测试呢?为什么我们需要用一些假对象来替换我们测试类中的真对象呢?原因是我们想让自己的单元测试是密闭独立的,实际测试时,任何一个类都有可能依赖于其他的类,这些依赖可能来自于同一源代码的同一根目录,可能来自一些核心库(java.util.ArrayList, java.io.File),更有一大部分来自于第三方库。或许这些依赖的输出是稳定且我们可以预期的,但实际生产环境中,它们可能会依赖于文件系统、网络等这些变幻莫测的外部资源,比如任何一个使用当前日期/时间或读取硬件资源的对象,其结果对我们来说都是不可预知的,而这样的不可预知,对于单元测试来说,就是最大的bug。
在单元测试中,我们需要保证除了我们要测试的类,其“外部世界”的行为与输出与我们所预期的完全一致。举个栗子,比如我们需要测试一个service,这个service作用是根据各国的区号,计算当前国家的税率。
double taxRate = TAXService.getTAXRateForCountry(countryCode);
比如在单测case中,我们假设美国的税率是21%,但是除非我们ctrl+鼠标点击进去TAXService这个类中去查看,我们无法得知是否真的是我们所预期的21%。有可能TAXService类依赖于本地文件,也有可能会去服务器中去查,而查询本地文件,或者连接服务器这一动作,就大大降低了我们单元