听说优秀的程序员20%的时间都在写UT？

在今天的文章中打算和大家聊一聊关于测试的话题，也许有朋友会问，作为一名码农为什么要关注测试的问题们把代码开发完基本自测没问题了，扔给测试不就行了问题再改呗！也许有很多人都会这么想，的确，目前国内很多程序员并不太关注Unit Test，很多互联 公司也并没有强制要求开发人员必须编写Unit Test Case。究其原因，可能是国内公司都比较有钱，测试团队动辄几十人，甚至上百人的公司大有人在。所以，从很多程序员的心态上看，测试这么多，直接扔给他们测试就好了！而另外一个被提及的原因，则是国内互联 公司产品迭代速度太快，需求太多做不过来，那里有时间写Unit Test呢/p>

也许原因是多样的，但抛开各种各样的因素，今天我们只从程序员成长的角度来聊一聊该不该写Unit Test近这段时间和海外的程序员朋友合作开发项目比较多，给我的感受是他们特别强调Unit Test，用他们的话来说比较在意程序的品质。而反观国内很多公司这一点做的就并不是那么好了！之前也和他们聊过其中的原因，他们认为是国内最近这些年的发展太快了，以至于有些过程被跳过了。

我们知道开发一个软件或者平日里在现有的项目中开发某个需求时，严格来说一般会经历这么一个流程，如下图所示：

在上面我们谈到了在编写业务层Unit Test时候会发现复杂的组件依赖需要我们编写很多额外的Mock类，增加来我们编写Unit Test的难度，而Mockito这个测试框架的出现则让Mock这件事变得非常容易了！Mockito是一个模拟测试框架，可以让我们以注解（@MockBean）的方式优雅地进行依赖组件的Mock并对执行逻辑进行验证。使用Mockito的一般步骤如下：

一般来说Unit Test类的代码接口与实际源码结构一致就行，以被测试类+Test后缀命名即可。接下来我们编写该测试代码：

在以上测试代码中我们通过@MockBean这个注解就很容易的Mock了该业务层代码的依赖组件，这样测试代码在执行依赖组件的逻辑时就会被Mock而不会真正调用这个方法。而一般情况下我们也可以验证下Mock对象的方法是否有被调用，但是只是验证下调用本身是否触发而并不是真的调用，可以使用given/verify这两个Mocktio提供的方法来实现。

对于大部分情况采用这样的模式进行Unit Test就差不多了，更多其他细节的用法大家可以在好好研究下Mocktio提供的功能！在这里示例中还有个一个小的技巧，就是我们在使用@SpringBootTest的时候如：

可以直接指定要测试的Service类，这样Spring Boot就不会加载其他乱七八糟的依赖了，这样会节约Unit Test运行的时间。