历史遗留代码不敢重构?
每次改代码都要回归所有逻辑?
提测被打回?
在近期的代码重构的过程中,遇到了各式各样的问题。比如调整代码顺序导致bug,取反操作逻辑丢失,参数校验逻辑被误改等。
上线前需要花大量时间进行测试和灰度验证。在此过程最大的感受就是:一切没有单测覆盖的重构都是裸奔。
经历了没有单测痛苦磨难,查阅很多资料和实战之后,于是就有了这篇文章,希望能给你的单测提供一些参考。
认识单测
· What
单元测试是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。
关于测试的名词还有很多,如集成测试,系统测试,验收测试。是在不同阶段,不同角色来共同保证系统质量的一种手段。
笔者在工作中经常遇到一些无效单测,通常是启动Spring容器,连接数据库,调用方法然后控制台输出结果。这些并不能算是单测。示例代码如下:
Copy@RunWith(SpringRunner.class)
@SpringBootTest(classes = ApplicationLoader.class)
public class UserServiceTest {
@Autowired
private UserService userService;
@Test
public void testAddUser() {
AddUserRequest addUserRequest = new AddUserRequest("zhangsan", "zhangsan@163.com");
ResultDTO<Long> addResult = userService.addUser(addUserRequest);
System.out.println(addResult);
}
}
· Why
在工作中很多代码是没有单测的,这些项目也能正常的运行。那么为什么要编写单测呢?
好的单测在能够提供我们代码交付质量的同时,减少bug发现和修复的成本,进而提高工作效率。至于单测能够让QA开心,则只是锦上添花。
提升工作效率,在工作中程序员的大多数时间都耗费在了测试阶段,编码往往可能只占一小部分。
尤其是在修改已有代码时候,不得不考虑增量代码是否会对原有逻辑带来冲击,以及修复bug之后是否引入的新的bug。
笔者就曾陷入如此困境,一下午时间都在重复着打包,部署,测试...,在改bug和写bug之间无限循环,有时也会因为一个低级bug抓心挠肝刚到后半夜。
所以长远来看,单测是能够有效提高工作效率的!
提升代码质量,可测试通常与软件的设计良好程序相关,难以测试的代码一般设计上都有问题。所以有效的单测会驱动开发者写出更高质量代码。
当然,单测带来最直接的收益就是能够减少bug率,虽然单测不能捕获所有bug,但是的确能够暴露出大多数bug。
节省成本,单测能够确保程序的底层逻辑单元的正确性,让问题能够在RD自测阶段暴露出来。bug越早发现,修复成本往往更低,带来的影响也会更小,所以bug应该尽早暴露。
如下图红色曲线所示,在不同阶段修复bug的成本差别是巨大的。
· Who
代码的作者最了解代码的目的、特点和实现的局限性。写单测没有比作者更适合的人选了,所以往往代码作者往往是第一责任人。
· When
编写单测的时机,一般是 The sooner, the better(越早越好)。尽量不要将单测拖延到代码编写完之后,这样带来的收益可能不尽如人意。
TDD(Test-Driven Development)测试驱动开发,是一种软件开发过程中的应用方法,以其倡导先写测试程序,然后编码实现其功能得名。
测试驱动着整个开发过程:首先,驱动代码的设计和功能的实现;其后,驱动代码的再设计和重构。
当然TDD是一种理想的状态,由于种种原因,想要完全遵守TDD原则,是有一定难度的,毕竟PM的需求往往是可变的。
边开发边写单测,先写少量功能代码,紧接着写单测,重复这两个过程,直到完成功能代码开发。
其实这种方案跟第一种已经很接近,当功能代码开发完时,单测也差不多完成了。这种方案也是最常见和推荐的方式。
开发后再补单测,效果往往是最差的。首先,要考虑的是代码的可测性,已经完成的代码可能并不具备可测试性,毕竟写代码的时候可以任意发挥。
其次,补单测时容易顺着当前实现去写测试代码,而忽略实际需求的逻辑是什么,导致我们的单测是无效的。
· Which
究竟哪些方法需要进行单测?这个困扰笔者很久的一个问题!如上文所说,单测覆盖率当然是越高越好,不过我们在考虑ROI时难免会做出一些妥协。
接受不完美,对于历史代码,全覆盖往往是不现实的。我们可以根据方法优先级(如照成资损,影响业务主流程)针对性补全单测,保证现有逻辑能正常运行。
对于增量代码,笔者认为没有必要全部覆盖,一般根据被测方法是否有处理(业务)逻辑来决定。
比如常见的JavaWeb项目代码中,Controller层,DAO层以及其他仅涉及接口转发相关的方法,往往不需要单测覆盖。而业务逻辑层的各种Service则需要重点测试。
对于自定义的工具类,正则表达式等固定逻辑,也是必须要测试的。因为这部分逻辑一般都是公共且通用的,一旦逻辑错误会产生比较严重的影响。
· How
好的单测一定是能够自动执行并查执行结果的,也不应当对外部有依赖,单测的执行应当是完全自动化,并且无需部署,本地IDE就能运行。
在写单词前,不妨参考以下前人总结好的First原则。
F—Fast:快速
在开发过程中通常需要随时执行测试用例;在发布流水线中执行也必须执行,常见的就是push代码后,或者打包时先执行测试用例;况且一个项目中往往有成百上千个测试用例。
所以为了保证开发和发布效率,快速执行是单测的重要原则。这就要求我们不要像集成测试一样依赖多个组件,确保单测在秒级甚至毫秒级执行完毕。
I—Isolated:隔离
隔离性也可以理解为独立性,好的单测是每个测试用例只关注一个逻辑单元或者代码分支,保证单一职责,这样能更清晰的暴露问题和定位问题。
每个单测之间不应该产生依赖,为了保证单测稳定可靠且便于维护,单测用例之间决不能互相调用,也不能依赖执行的先后次序。
数据资源隔离,测试时不要依赖和修改外部数据或文件等其他共享资源,做到测试前后共享资源数据一致。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理