单元测试.md 2.9 KB
单元测试
为什么项目中要编写单元测试
先理解下单元测试，编写、运行单元测试本质上核心就只有一个，为了准确保证代码运行的结果与我们开发者期望的返回值保持一致。同时单元测试属于 CI / CD 的核心流程之一，正是因为有了单元测试、Docker等，才能让DevOps 落地于实践、自动化所有流程。
回归正题、为什么要编写单元测试？旨在
提高软件程序的质量
尽可能避免、甚至规避
bug出现较少重复性的开发工作与时间，比如测试调试
让开发者更加有信息地、安全地重构代码
编写单元测试更是对自己代码负责人的体现。
由于历史原因，过去的项目中前后端都没有很完善的单元测试，必须规范前后端都引入并落地单元测试，这是今后的一个重点工作。
单元测试的特点与要求
单元测试必须遵循
AIR原则，即遵循自动化(Automatic)、独立性(Independent)、可重复(Repeatable)三大原则单元测试必须全流程自动执行、不需要人工干预，即非交互式
单元测试必须保持独立性
即单元测试用例之间禁止互相调用，也不能依赖执行的先后顺序。
- 单元测试必须可重读执行，并且不受外部环境影响
单元测试的测试用例是会在持续集成环境中运行的，假设是对外界有强依赖的关系，那么会造成持续集成机制不可用。
- 单元测试目录规划
单元测试的目录位于 /test
- 项目核心部分务必编写、通过单元测试
核心部分包括核心业务、核心底层封装模块、核心应用等
- 单元测试必须遵循质量交付
BCDE原则
Border : 边界值测试
Correct : 正确的输入，并得到预期的结果
Design : 与设计文档相结合，来编写单元测试
Error : 强制错误信息输入，并得到预期的结果
Q&A
先编码还是先编写单元测试
嗯、有部分人建议是编编写单元测试再编业务代码，可能你会存在疑问、没有业务代码可以编写单元测试？？？嗯、是可以的，先来一个业务交互流程图、然后通过写伪代码或者建模的方式来解决这个问题。
但是还是建议先写业务代码再编写单元测试，根据需求的业务交互流程图来写真正的业务代码才是正常的业务编码，同时是正确的对流程的理解与程序还原的姿势。
谁来编写单元测试
毋庸置疑的是开发者来编写的，自己的代码自己编写单元测试，也可以由别的开发者编写。
单元测试覆盖率
覆盖率的话没有具体的数值，但是要对核心的、必要的、关键的代码或者业务流程做单元测试，同时避免无用的单元测试，比如标准库、成熟的依赖库等。