单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。在测试金字塔模型中处于最底层:
整个金字塔模型代表着越上层的测试集成度越高,执行速度越慢,越下层的测试隔离性越好,执行越快越轻量。
单元测试应该由开发人员来做?还是由测试人员来做?分析一下会发现两者都各有利弊:
开发人员做:
优势:编码能力更强,对系统的掌握度更高,编写测试脚本效率更快;
劣势:测试观念较薄弱,覆盖场景不全面。自己测自己的代码,可能会放水,测试质量不高;
测试人员做:
优势:能设计更全面的测试用例,覆盖率更高。测试更严格,测试质量更高;
劣势:编码能力偏弱,编写测试脚本效率低;
实际工作中,推荐采用TDD模式,由测试人员先编写单元测试的测试用例,开发人员来进行实现。类似于结对编程方式,既保障了单元测试的覆盖率和测试质量,又保障了测试脚本编写的效率,也是测试左移的实践之一。
Mac快捷键:cmd+shift+T,windows快捷键:Ctrl+Shift+T
点击OK,在项目的test目录下就会自动生成对应的单元测试类。
踩坑注意:
Junit运行时会碰到报错:No runnable methods
原因:自动生成的单元测试类,import的包是:import org.junit.jupiter.api.Test;
解决方法: 改为import org.junit.Test; 就不会报错了。
单元测试的编码规范:
类名: 定义测试类,类名是由被测试类名Test构成。例如:BugServiceImplTest
包名: 定义的测试类需要放在xxx.xxx.xxx.test包中。例如:package com.demo.test;
方法名: 测试方法的方法名通常定义为test+测试方法名,或者直接叫测试方法名。例如:testAddBug和addBug都可以
返回值: 因为我们的方法只是在类中测试,可以独立运行,所以不需要处理任何返回值,所以这里使用void。例如:public void add();
@Test注解:测试方法上方加@Test注解来执行测试,只要是加该注解的方法,可以单独运行此方法来完成测试。
假设有一个CommonUtils类,里面提供了一个获取当前时间并转换为年月日时分秒格式的方法:
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
public class CommonUtils {
/**
* Date转换为字符串的时间
* @return time "2022-03-09 19:13:42"
*/
public static String getCurrentTime() {
Date date = new Date();
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String time = formatter.format(date);
return time;
}
}
现在要对这个方法做单元测试,通过单元测试验证这个方法是否能正常转换输出时间。单元测试代码如下:
import com.test.utils.CommonUtils;
import org.junit.Test;
public class CommonUtilsTest {
@Test
public void dateTest(){
System.out.println("测试CommonUtils获取当前时间结果:"+CommonUtils.getCurrentTime());
}
}
单元测试输出结果:
可以看到该方法正常工作,说明方法代码没有问题,单元测试通过。
本篇文章主要介绍入门知识,单元测试更进一步的使用,欢迎查看我的下一篇文章:Service层代码单元测试以及单元测试如何Mock。
================================================================================================
以上就是本次的全部内容,都看到这里了,如果对你有帮助,麻烦点个赞+收藏+关注,一键三连啦~
欢迎下方扫码关注我的vx公众号:程序员杨叔,各类文章都会第一时间在上面发布,持续分享全栈测试知识干货,你的支持就是作者更新最大的动力~