前言

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

@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的使用