前言
这周一开始就参与了《商务网站入门》作业提交系统的开发,由于技术不到位,导致重置学生密码的功能重写了多次,写了好几天,主要时间都花在后台单元测试上了,真的是一点都不明白,然后多半天写功能,好几天写测试,基本上每一次都得请教宜衡学长,在此向李宜衡学长表示感谢。
@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是个很有意思的东西,也给人以乐趣吧,就像闯关游戏一样,一关一关闯过去,就能写完功能,希望自己早日达到这种水平吧。
总结
这一周真的挺虐心的,早起敲到晚上,除了吃饭睡觉就是敲代码,主要是对单元测试一窍不通,耽误了太多的时间,终于体会到了了工欲善其事必先利其器这句话的意义。
读了宜衡学长分享的博客,有一种恍然大悟的感觉,以前感觉实践是最好的老师,但我忽略了一个前提,那就是掌握一定的知识,啥也不会就实践,那纯粹是耽误时间。
特此鸣谢
感谢潘老师的指导,让我对开发有了更深的体会,感谢李宜衡学长和其他小伙伴的帮助。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。