单元测试的时机
什么时候去编写单元测试,一般会有三种方式:先写测试再开发、开发完成后写测试、功能完成且手动测试完后补上单元测试
这三种写测试的不同顺序会直接影响到开发体验,也是单元测试评价两极分化的原因:一部分认为单元测试会拖累交付效率,一部分认为单元测试是开发神器
开发后补测试
在功能实现并且通过手动测试后再去编写单元测试的行为称为后补测试
后补测试一般是因为硬性规定,导致不得不勉强补上测试,增加额外的工作量,是一种非常痛苦的过程
开发验证测试
在每一个小步骤的开发之后,通过单元测试验证功能是否实现。根据开发进程的不断推进,不断比对上下文环境的执行逻辑,确保每一步都符合预期,逐步完善整体的测试模块
在这种情况下,自动化测试会渐渐替换掉手动测试
UI 测试仍然是必须的
测试驱动开发
先写测试再在写功能,通过测试驱动功能实现,是敏捷开发的核心要素
其主要步骤有三个
- 先写一个失败的测试
以预期的调用方式去执行,因为没有实现逻辑,所以必然是失败的 - 再写使这个测试通过的业务代码
首先使代码能够编译通过,需要根据单测给出的报错信息去逐步的解决,这一过程就像闯关游戏一样,能够给‘玩家’一定的满足感 - 最后对业务代码进行重构
这一步骤并不是必须的,只是根据个人喜好对逻辑进行抽离封装