后台单元测试总结

前言

这周一开始就参与了《商务网站入门》做业提交系统的开发，因为技术不到位，致使重置学生密码的功能重写了屡次，写了好几天，主要时间都花在后台单元测试上了，真的是一点都不明白，而后多半天写功能，好几天写测试，基本上每一次都得请教宜衡学长，在此向李宜衡学长表示感谢。

@Autowired && @MockBean

在参照其余项目后台单元测试的时候发现自动装配Bean的两种注解@Autowired和@MockBean，也不知道有什么不一样，只记得看到过，具体怎么用也只是据说过，可是一到用就不会了，
@Autowired是自动装配一个真的Bean，你可使用它全部的的功能，可是不能控制它的功能，而@MockBean是装配一个Bean，这个Bean是克隆的，具备原来Bean的功能，可是受控制，咱们能够控制某个方法的执行结果。
以UserServiceImpl这个类的fingByUserName方法为例，

@Override
    public User findByUsername(String username) {
        return this.userRepository.findByUsername(username);
    }

写一个测试Demo

public class Demo extends ServiceTest {
    @MockBean
    UserServiceImpl userService;

    @Test
    public void findByUserName(){
        String username = RandomString.make(6);
        User Mockuser = new User();
        Mockuser.setUsername(username);
        User resultUser = new User();
        Mockito.when(userService.findByUsername(username)).thenReturn(resultUser);

        Assert.assertEquals(Mockuser.getId(),resultUser.getId());
    }
}

Mockito.when(userService.findByUsername(username)).thenReturn(resultUser);

上面的代码便实现了对findByUserName()方法的控制，此时的userService是mock出来的，在这行代码上打一个断点，看一下相关信息：

userService中的userRepository都是空的，说明该userRepository是模拟的，假如注入真正的userService，那么咱们就没法实现对方法的控制，只能添加数据发起真正的请求，断言数据相同，假如数据量较大，测试的难度就会大大增长。

依赖注入

经过宜衡学长分享的博客深刻了解了一下依赖注入，也算对依赖注入有了更深的了解。
把有依赖关系的类放到容器中，解析出这些类的实例，就是依赖注入，其目的是实现类的解耦。

控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，能够用来减低计算机代码之间的耦合度。其中最多见的方式叫作依赖注入（Dependency Injection，简称DI）。经过控制反转，对象在被建立的时候，由一个调控系统内全部对象的外界实体，将其所依赖的对象的引用传递给它。也能够说，依赖被注入到对象中。

依赖注入以前实现依赖关系：

依赖注入：

举个不太恰当但有助于理解的例子，在没有二手车APP或者二手车中介前，咱们想要找符合本身要求的二手车，就得四处打听，而有了APP和中介，他们搜集二手车信息，咱们只要说出本身的需求，中介或者APP就能根据需求提供相关信息或车辆。

经过依赖注入也顺便了解了控制反转，教程对控制反转有着这样的介绍：

Spring有两个特性： IOC与 AOP。 IOC即控制反转，因为太过于出名，而使得网上的文章有不少。大致的意思就是说：之前咱们须要某个对象是须要本身实例化出来的；而在 Spring中，咱们只须要声明本身须要一个具备什么功能的对象，至于最后获得的这个对象是谁，是由 Spring来控制来完的。在 IOC之前，对象是谁是在代码编写阶段来控制的；而有了 IOC之后，咱们在代码编写阶段放弃了控制了权限，而改由 Spring统一控制了。因为控制权发生了实质性的变动，因此是 控制反转了。

在自动注入实现以前，要想注入类，须要编程人员手动注入，编程人员拥有控制权，而拥有了Spring框架的IOC特性，Spring拥有了注入类的控制权，实现了控制的反转。
教程地址

TDD

TDD 是测试驱动开发（Test-Driven Development），它一样也是敏捷开发的一种方法论。TDD 是再开发代码以前，先编写单元测试用例，用测试的代码肯定要编写什么样的代码。它的整个思路就是经过测试来驱动整个软件开发的进度，固然这对测试人员来讲是一个更高的要求和标准。

TDD 三大原则：

• You are not allowed to write any production code unless it is to make a failing unit test pass.
• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

除非要使失败的单元测试经过，不然不容许编写任何生产代码。

不容许您编写的单元测试超过了失败的数量；编译失败就是失败。

不容许您编写超过足以经过一次失败的单元测试的生产代码。

固然对于如今的我来讲，水平确定差好多，可是感受TDD是个颇有意思的东西，也给人以乐趣吧，就像闯关游戏同样，一关一关闯过去，就能写完功能，但愿本身早日达到这种水平吧。

总结

这一周真的挺虐心的，早起敲到晚上，除了吃饭睡觉就是敲代码，主要是对单元测试一窍不通，耽误了太多的时间，终于体会到了了工欲善其事必先利其器这句话的意义。

读了宜衡学长分享的博客，有一种恍然大悟的感受，之前感受实践是最好的老师，但我忽略了一个前提，那就是掌握必定的知识，啥也不会就实践，那纯粹是耽误时间。

特此鸣谢

感谢潘老师的指导，让我对开发有了更深的体会，感谢李宜衡学长和其余小伙伴的帮助。

参考资料

徒手撸框架--实现IoC
什么是【TDD】
@MockBean的使用