淘系用户平台技术团队单元测试建设

简介: 纵观优秀的开源工程,完备的单元测试总是必须的条件。通过这些单元测试,我们可以充分了解代码中相关类和方法的作用和核心逻辑,熟悉各种场景的运行情况。同时也因为有了单元测试,开源作者在接受各种feature的代码提交时才有稳定安全的保障。其实单元测试的重要性所有开发同学应该都了然于胸,同样TDD(测试驱动开发)也不是一个新的概念,但是真当我们落地实践时,又总会找出各种各样的理由来劝服自己下次一定好好写单元测试,这一次先放过自己。这些理由无外乎,开发周期太紧了; 测试同学能保证功能正确性;写单元测试代码量比业务代码还大; 又不是不能跑。虽然我们总是在追逐工程师文化,却又时不时放纵在放弃工程师底蕴的路上

一. 为什么需要单元测试

纵观优秀的开源工程,完备的单元测试总是必须的条件。通过这些单元测试,我们可以充分了解代码中相关类和方法的作用和核心逻辑,熟悉各种场景的运行情况。同时也因为有了单元测试,开源作者在接受各种feature的代码提交时才有稳定安全的保障。其实单元测试的重要性所有开发同学应该都了然于胸,同样TDD(测试驱动开发)也不是一个新的概念,但是真当我们落地实践时,又总会找出各种各样的理由来劝服自己下次一定好好写单元测试,这一次先放过自己。这些理由无外乎,开发周期太紧了; 测试同学能保证功能正确性;写单元测试代码量比业务代码还大; 又不是不能跑。所以虽然我们总是在追逐工程师文化,却又时不时放纵在放弃工程师底蕴的路上。

      单元测试是工程交付前质量保障的第一环,也无疑是软件工程质量保障的重要基石,有效的单元测试能够提前发现90%以上的代码Bug问题,同时也能防止代码的腐化,在工程重构演进时起到至关重要的作用。

二. 怎么写单元测试

2.1 好的单元测试的几个要点

摘自阿里巴巴开发规约

  • 单元测试必须遵守AIR原则,单元测试必须具备Automatic(自动化),Independent(独立性),Repeatable(可重复)性
  • 单元测试应该是全自动执行的,并且非交互式的。测试用例通常是被定期执行的,执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。
  • 单元测试要保证测试粒度足够小。单元测试测试粒度足够小,有助于精确定位问题。单测粒度至多是类级别,一般是方法级别。
  • 单元测试要遵守BCDE原则,Border,边界值测试,包括循环边界、特殊取值、特殊时间点、数据顺序等;Correct,正确的输入,并得到预期的结果;Design,与设计文档相结合,来编写单元测试;Error,强制错误信息输入(如:非法数据、异常流程、非业务允许输入等),并得到预期的结果
  • 核心业务、核心应用、核心模块的增量代码要确保单元测试通过

2.2 单元测试编码范式

这里主要以Mockito单元测试框架为模版

  1. Mock :  通过when().thenReturn/thenAnswer/thenThrow 或者doReturn().when()等mock方式将依赖类方法进行模拟,模拟服务依赖或者中间结果
  2. DO :   调用被测试类方法,执行测试链路
  3. Verify :  校验执行结果正确性,通过Assert校验数据结果准确,通过Verify校验链路执行准确,通过expected=Exception.class校验异常链路
publicclassTest {
// 0. 依赖类@MockDependencyClassdependencyClass;
// 0. 待测试类@InjectMocksTestClasstestClass;
@BeforepublicvoidsetUp() {
MockitoAnnotations.initMocks(this);
    }
@TestpublicvoidtestMethod() {
// 1. Mock, 依赖方法,构造中间层数据when(dependencyClass.someMehod(any())).thenReturn(mockData());
// 2. Do, 调用被测试类Resultresult=testClass.testMehod();
// 3. Verify, 校验结果数据Assert.assertEquals("some expected result string", result.getModel());
    }
}


当然写单元测试用例虽然套路比较模版化,但是我们也要充分利用单元测试框架(Junit/Mockito/PowerMock/Spock),掌握其中的一些技巧,才能写出快准狠的单元测试用例,这也是研发同学必须要掌握的基本功。关于如何利用单元测试框架这里不再赘述(详细可以参考阿里技术《Java编程技巧之单元测试用例编写流程》)。

2.3 单元测试编码提效

IDEA上有很多单元测试插件,能够半自动化生成单元测试类文件,这里重点推荐TestMe插件。TestMe插件可以智能分析被测试类的依赖类,结合Mockito+Junit等单元测试框架,生成Mock/InjectMocks依赖关系,自动生成单元测试类。

假设业务代码如下:

@ComponentpublicclassDefaultMemberManagerimplementsMemberManager {
@AutowiredprivateMemberDAOmemberDAO;
@AutowiredprivateCacheManagercacheManager;
@OverridepublicDatequeryActivationTime(longuserId) {
DateactivationTime=cacheManager.getActivationTime(userId);
if (activationTime==null) {
MemberDOmemberDO=memberDAO.queryByUserId(userId);
if (memberDO!=null) {
cacheManager.saveActivationTime(userId, memberDO.getActiveTime());
activationTime=memberDO.getActiveTime();
            }
        }
returnactivationTime;
    }
}


则通过TestMe快捷键COMMOND+N, 可以极速自动生成如下的单元测试类

publicclassDefaultMemberManagerTest {
@MockMemberDAOmemberDAO;
@MockCacheManagercacheManager;
@InjectMocksDefaultMemberManagerdefaultMemberManager;
@BeforepublicvoidsetUp() {
MockitoAnnotations.initMocks(this);
    }
@TestpublicvoidtestQueryActivationTime() throwsException {
when(memberDAO.queryByUserId(anyLong())).thenReturn(null);
when(cacheManager.getActivationTime(anyLong())).thenReturn(
newGregorianCalendar(2022, Calendar.MARCH, 5, 23, 2).getTime());
Dateresult=defaultMemberManager.queryActivationTime(0L);
Assert.assertEquals(newGregorianCalendar(2022, Calendar.MARCH, 5, 23, 2).getTime(), result);
    }
}


三. 团队单元测试建设

3.1 覆盖率概念

覆盖率是类JaCoCo插件通过javaagent挂载的方式,在单元测试命令运行时执行代码覆盖率检测,计算单元测试执行过程中所覆盖的代码比例来生成覆盖率。常见的覆盖率指标,又可进一步细分为语句覆盖率,条件覆盖率,分支覆盖率,路径覆盖率等。这里我们当前更为关注语句覆盖率和分支覆盖率,尤其是增量代码的覆盖率,更能体现变更代码的单元测试覆盖情况。

3.2  如何进行单元测试

这里我们借助于阿里研发平台Aone的测试实验室功能,Aone实验室支持测试任务插件的编排组合,通过独立的测试资源执行测试任务。所以我们将代码拉取插件,单元测试插件和覆盖率计算插件进行编排配置,形成最终的执行流:拉取代码;执行单元测试命令;单元测试结果解析; 计算覆盖率。最终完成整个工程的单元测试覆盖率计算。

单元测试覆盖率结果示例如下

3.3  什么时候触发单元测试

单元测试任务主要通过持续交付流水线pipeline来集成,当前几个主要触发策略如下

  1. 代码提交时,保证单元测试执行及时性
  2. 代码审核时,保证代码审核通过的代码分支符合单元测试标准
  3. 发布流程中,保证最终集成发布的所有分支代码符合单元测试标准

3.4  单元测试覆盖率卡点

用户平台技术团队单元测试规范如下:

  • 单元测试用例通过率为100%
  • 单元测试增量代码行覆盖率为85%
  • 代码规范扫描增量问题总数为0个

3.5 单元测试覆盖率报表

为了更好的衡量单元测试的覆盖率情况,我们采用报表的形式统计每个应用,每个团队的代码单元测试覆盖率。

四. 总结

当前团队内各应用(除边缘应用外)的单元测试增量代码覆盖率在2022年已经全部达到85%标准,最新平均增量代码行覆盖率达到88%,整体全量代码覆盖率平均提高20%。诚然单元测试覆盖率的提高不是最终的目的,覆盖率高不能完全代表工程质量高,但是一个没有单元测试或者单元测试覆盖率低的工程,其代码质量和稳定性必然不高。同时团队内研发同学对单元测试也有了新的认识,自测和提测质量显著提升,全年未发生由于代码质量产生的线上故障,有效提升了工程质量和服务稳定性。

     后续规划,持续优化单元测试质量,提升分支覆盖率,优化边界异常覆盖;关注单元测试编码效率的提升,优化测试用例和测试数据分离;关注核心链路单元测试覆盖率;熟练将TDD思维运用到业务开发过程中。


团队介绍

大淘宝技术-用户平台技术团队
用户平台技术团队是一支集研发、数据、算法一体的团队,负责淘系的用户增长,游戏互动,平台会员和私域运营等消费者核心业务。在对用户争夺进入白热化的时期,团队正承担着捍卫电商主板块增长的重要使命,是阿里核心电商战场的参与者,用持续的技术创新来驱动阿里电商引擎的稳步前行。
这是一支年轻开放的团队,在这里你将收获超大规模高并发场景的架构设计能力,洞悉用户增长最前沿的实践方法,在数字化时代收获最核心的竞争力。团队技术氛围浓厚,倡导创新和工程师文化,鼓励用数据和代码发现解决问题。团队研发流程规范,代码质量高,学习成长速度快。
如果您有兴趣可将简历发至wangliyuan.wly@alibaba-inc.com,期待您的加入。

目录
相关文章
|
2月前
|
资源调度 测试技术 Linux
一款接口自动化神器—开源接口测试平台Lim(Less is More)
一款接口自动化神器—开源接口测试平台Lim(Less is More)
126 2
|
4月前
|
分布式计算 测试技术 Spark
通过Langchain实现大模型完成测试用例生成的代码(可集成到各种测试平台)
通过Langchain实现大模型完成测试用例生成的代码(可集成到各种测试平台)
630 0
|
29天前
|
缓存 运维 Serverless
应用研发平台EMAS产品常见问题之测试检查更新没有反应如何解决
应用研发平台EMAS(Enterprise Mobile Application Service)是阿里云提供的一个全栈移动应用开发平台,集成了应用开发、测试、部署、监控和运营服务;本合集旨在总结EMAS产品在应用开发和运维过程中的常见问题及解决方案,助力开发者和企业高效解决技术难题,加速移动应用的上线和稳定运行。
|
1月前
|
机器学习/深度学习 人工智能 监控
视觉智能平台常见问题之体验产品的美颜测试关掉如何解决
视觉智能平台是利用机器学习和图像处理技术,提供图像识别、视频分析等智能视觉服务的平台;本合集针对该平台在使用中遇到的常见问题进行了收集和解答,以帮助开发者和企业用户在整合和部署视觉智能解决方案时,能够更快地定位问题并找到有效的解决策略。
23 1
|
2月前
|
测试技术
Lim测试平台测试报告说明
Lim测试平台测试报告说明
32 2
|
2月前
|
SQL 测试技术 数据库连接
Lim接口测试平台-接口测试功能详解
Lim接口测试平台-接口测试功能详解
39 1
|
2月前
|
SQL 监控 测试技术
Lim测试平台变量使用规则介绍
Lim测试平台变量使用规则介绍
27 0
|
2月前
|
测试技术
使用Lim测试平台快速完成批量造数
使用Lim测试平台快速完成批量造数
31 1
|
2月前
|
SQL JSON 监控
Lim测试平台快速上手教程
Lim测试平台快速上手教程
38 0
|
2月前
|
测试技术 Linux 数据安全/隐私保护
如何远程访问Linux MeterSphere一站式开源持续测试平台
MeterSphere 是一站式开源持续测试平台, 涵盖测试跟踪、接口测试、UI 测试和性能测试等功能,全面兼容 JMeter、Selenium 等主流开源标准,有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试,加速高质量的软件交付,推动中国测试行业整体效率的提升。