一、什么是单元测试？（10 min）
单元测试和集成测试的区别
回到测试的本质来看，测试工作就是模拟真实环境，在代码正式上线前进行验证的工作，即使没有任何工具和方法，这项工作也能够通过人工操作来手动完成。但这种方式显然不符合软件从业者的习惯，于是开始出现了各种各样的自动化测试方法，框架和工具。单元测试和集成测试使用的测试框架和工具大部分是相同的，而社区中对集成测试的介绍不尽相同，导致很多看过不同文章的同学对这两种测试的认知存在争议。
首先需要达成一致的是，无论是单元测试还是集成测试，它们都是自动化测试。为了更好地区分，我们可以这样理解：和生产代码以及单元测试代码在同一个代码仓库中，由开发同学自己编写的，对外部环境（数据库、文件系统、外部系统、消息队列等）有真实调用的测试就是集成测试。下表中也从各种角度来对比了单元测试、集成测试和系统级别测试（包括端到端测试、链路测试、自动化回归测试、UI测试等）的区别。
单元测试 | 集成测试 | 系统级别测试 | |
编写人员 | 开发 | 开发 | 开发 / 测试 |
编写场地 | 生产代码仓库内 | 生产代码仓库内 | 生产代码仓库内 / 生产代码仓库外 |
编写时间 | 代码发布前 | 代码发布前 | 代码发布前 / 代码发布后 |
编写成本 | 低 | 中 | 高 |
编写难度 | 低 | 中 | 高 |
反馈速度 | 极快，秒级 | 较慢，分钟级 | 慢，天级别 |
覆盖面积 | 代码行覆盖60-80% 分支覆盖40-60% | 功能级别覆盖HappyPath | 核心保障链路 |
环境依赖 | 代码级别，不依赖环境 | 依赖日常或本地环境 | 依赖预发或生产环境 |
外部依赖模拟 | 全部模拟 | 部分模拟 | 不模拟，完全使用真实环境 |
小互动（10 min）
上手题 - 用于查看目前大家的单测理解和技能水平
以下是一个简单的服务代码，请认真观看后写下你认为应该写的单元测试。
@Service
public class UserService {
/** 定义依赖对象 */
/** 用户DAO */
@Autowired
private UserDAO userDAO;
/**
* 查询用户
*
* @param companyId 公司标识
* @param startIndex 开始序号
* @param pageSize 分页大小
* @return 用户分页数据
*/
public PageDataVO<UserVO> queryUser(Long companyId, Long startIndex, Integer pageSize) {
//入参校验
if(ValidationUtil.validate(companyId)){
throw new InvalidRequestException(companyId, "Invalid company Id");
}
// 查询用户数据
// 查询用户数据: 总共数量
Long totalSize = userDAO.countByCompany(companyId);
// 查询接口数据: 数据列表
List<UserVO> dataList = null;
if (NumberHelper.isPositive(totalSize)) {
dataList = userDAO.queryByCompany(companyId, startIndex, pageSize);
}
// 返回分页数据
return new PageDataVO<>(totalSize, dataList);
}
}随机问题：
- 你觉得针对这段代码，应该需要写几个单元测试？
- 你觉得这个单元测试的行覆盖率理论值可以达到多少？我们一般需要达到多少？如果要达到你的目标，投入的工作量是多少？
- 单测的代码量和原业务代码量的比值应该是多少比较合适？
答案（仅供参考）：
@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {
/** 定义静态常量 */
/** 资源路径 */
private static final String RESOURCE_PATH = "testUserService/";
/** 模拟依赖对象 */
/** 用户DAO */
@Mock
private UserDAO userDAO;
/** 定义测试对象 */
/** 用户服务 */
@InjectMocks
private UserService userService;
/**
* 测试: 查询用户-无数据
*/
@Test
public void testQueryUser_Succeed_NoData() {
// 模拟依赖方法
// 模拟依赖方法: userDAO.countByCompany
Long companyId = 123L;
Long startIndex = 90L;
Integer pageSize = 10;
Mockito.doReturn(0L).when(userDAO).countByCompany(companyId);
// 调用测试方法
String path = RESOURCE_PATH + "testQueryUserWithoutData/";
PageDataVO<UserVO> pageData = userService.queryUser(companyId, startIndex, pageSize);
String text = ResourceHelper.getResourceAsString(getClass(), path + "pageData.json");
Assert.assertEquals("分页数据不一致", text, JSON.toJSONString(pageData));
// 验证依赖方法
// 验证依赖方法: userDAO.countByCompany
Mockito.verify(userDAO).countByCompany(companyId);
// 验证依赖对象
Mockito.verifyNoMoreInteractions(userDAO);
}
/**
* 测试: 查询用户-有数据
*/
@Test
public void testQueryUser_Succeed_WithData() {
// 模拟依赖方法
String path = RESOURCE_PATH + "testQueryUserWithData/";
// 模拟依赖方法: userDAO.countByCompany
Long companyId = 123L;
Mockito.doReturn(91L).when(userDAO).countByCompany(companyId);
// 模拟依赖方法: userDAO.queryByCompany
Long startIndex = 90L;
Integer pageSize = 10;
String text = ResourceHelper.getResourceAsString(getClass(), path + "dataList.json");
List<UserVO> dataList = JSON.parseArray(text, UserVO.class);
Mockito.doReturn(dataList).when(userDAO).queryByCompany(companyId, startIndex, pageSize);
// 调用测试方法
PageDataVO<UserVO> pageData = userService.queryUser(companyId, startIndex, pageSize);
text = ResourceHelper.getResourceAsString(getClass(), path + "pageData.json");
Assert.assertEquals("分页数据不一致", text, JSON.toJSONString(pageData));
// 验证依赖方法
// 验证依赖方法: userDAO.countByCompany
Mockito.verify(userDAO).countByCompany(companyId);
// 验证依赖方法: userDAO.queryByCompany
Mockito.verify(userDAO).queryByCompany(companyId, startIndex, pageSize);
// 验证依赖对象
Mockito.verifyNoMoreInteractions(userDAO);
}
@Test
public void testQueryUser_Fail_WithBadInput() {}
}抢答题：
- 请问这个是单元测试吗？
@RunWith(MockitoJUnitRunner.class)
public class SpringDalTest{
@Resource
DBClient dbClient;
@Test
public void testGetDate_success_getFromDB(){
String result = dbClient.getDate("Request");
Assert.equals(result,"ExpectedResults");
}
}- 请问这个是单元测试吗？
@RunWith(MockitoJUnitRunner.class)
public class DemoControllerTest {
@Mock
DemoTairClient tairClient;
@Mock
DemoDBMapper dbMapper;
@InjectMocks
DemoController demoController;
@Test
public void testGetResult_succeed_getFromCache() throws Exception {
when(tairClient.getCache(anyString())).thenReturn("getCacheResponse");
when(dbMapper.queryData(anyString())).thenReturn("queryDataResponse");
String result = demoController.getResult("request");
Assert.assertEquals("getCacheResponse", result);
}
}- 请问这个是单元测试吗？
@RunWith(PandoraBootRunner.class)
@DelegateTo(SpringJUnit4ClassRunner.class)
@PropertySource(value = {"classpath:test.properties", "classpath:landlord.properties"})
@SpringBootTest(classes = Application.class)
public class SanityTest{
@Resource
InfoService infoService1;
@Mock
InfoService infoService2;
public void testGetInfo_succeed_giveValidRequest(){
String result1 = infoService1.getInfo("Request");
String result2 = infoService2.getInfo("Request");
Assert.equals(result1,result2);
}
}二、为什么要写单元测试？（10 min）
反例：现在，领导要响应集团提高代码质量的号召，需要提升单元测试的代码覆盖率。当然，我们不能让领导失望，那就加班加点地补充单元测试用例，努力提高单元测试的代码覆盖率。至于单元测试用例的有效性，我们大抵是不用关心的，因为我们只是面向指标编程。1230 提升到 LV3，331 提升团队成为卓越工程 LV4， FY23 KPI 完成了，岂不是___，___，____?
正例：因为我是一名专业的计算机工程师。
理论上单元测试带来的好处有：
- 单测成本低，速度快。
- 单测是最佳的、自动化的、可执行的文档。
- 测试的要诀是：测试你最担心出错的部分，这样你就能从测试工作中得到最大的利益，100%覆盖率的单测会逐渐消磨开发人员对测试的耐心和好感。
- 单测驱动设计，提升代码简洁度，确保安全重构，代码修改后，单测仍然能通过，能够增强开发者的信心。
- 快速反馈，更快的发现问题。
- 定位缺陷比集成测试更快更准确，降低修复成本。
实际上通过 2 个公司内部的例子来证明：
例子 1
菜鸟 GOC 提供的一个外部 BU 的例子，仅供参考（对照组数据不够严谨，数据还待完善，结论进一步佐证中）
外BU：采销供应链--网络&权限&商家&采购&物流协同（后面简称伍道团队)单测缩短了变更的开发和测试总时长
1、变更开发测试时长领先
从阿里大脑获取到 FY22 5月-10月采购供应链-伍道团队，和供应链BU变更开发测试时长对比趋势的客观数据，如下图所示。对比6个月平均数来看，伍道团队变更开发测试时长平均领先供应链BU 3.1天。
2、交付质量高：变更折返修改代码再部署次数更低
采购供应链的有变更发布的全应用和BU内非采购供应链全应用，将变更平均从预发环境折返修改代码重部署次数做对比——5-10月份采购供应链“变更平均从预发环境折返修改代码重部署”次数为X次，同BU其他部门平均次数Y次，相比低40%。
从Aone中应用，针对5-10月供应链BU在预发环境有发布成功的变更的核心应用，我们将非采购供应链所有核心应用49个(Aone未观察有UT覆盖率)，和采购供应链主版本应用中，单测行覆盖率超60%的7个核心应用做参照对比。说明进行单测并没有使得变更的开发和测试时长变长，反而因为提升了代码内建质量，缩短了变更的开发和测试总时长。
例子 2
菜鸟&企业智能：企业智能单测减少了变更从预发环境平均折返修改代码重部署次数
菜鸟整体（单测一般）、企业智能（单测好）、A&B团队（单测差），对比7-10月变更从预发环境平均折返修改代码重部署次数。—— 企业智能返工次数明显低于菜鸟整体，低于菜鸟整体35%，低于单测建设薄弱团队整体45%。
7-10月，企业智能5个BU核心应用平均全量行覆盖≥60% 以及 菜鸟其他团队 5个 无单测建设的BU核心应用对比变更从预发环境平均折返修改代码重部署次数。——变更平均从预发环境折返修改代码重部署次数为X，低于5个无单测应用对照组的Y，说明经过充分的单测的变更的内建质量更好，因而在预发环境折返修改代码重部署次数比对照组低52%
三、怎么写单元测试？（50 min）
