单元测试的规范

1、测试准则

必须知足AIR原则

A：Automatic（自动化）
I：Independent（独立性）
R：Repeatable（可重复）

可参照27条准则。
引用连接：https://blog.csdn.net/neo_ustc/article/details/22612759
原文连接：https://petroware.no/unittesting.html
以下：

27条准则

   
  1. 保持单元测试小巧, 快速
2. 单元测试应该是全自动/非交互式的
3. 让单元测试很容易跑起来
4. 对测试进行评估
5. 当即修正失败的测试
6. 把测试维持在单元级别
7. 由简入繁
8. 保持测试的独立性
9. Keep tests close to the class being tested
10. 合理的命名测试用例
11. 只测试公有接口
12. 当作是黑盒
13. 当作是白盒
14. 芝麻函数也要测试
15. 先关注执行覆盖率
16. 覆盖边界值
17. 提供一个随机值生成器
18. 每一个特性只测一次
19. 使用显式断言
20. 提供反向测试
21. 代码设计时谨记测试
22. 不要访问预约的外部资源
23. 权衡测试成本
24. 合理安排测试优先次序
25. 为测试失败作好准备
26. 写测试用例重现 bug
27. 了解局限

2、结构规范

目录结构规范：

1.源码存放在src目录，每一个功能模块建立单个npm包
2.src同级建立test/unit做为单元测试文件目录
3.test/unit目录下建立源npm包同名文件夹，用于存放单元测试文件
4.src同级建立test/integration做为集成测试文件夹
5.test/integration目录下建立源npm包同名文件夹，用于存放集成测试文件

文件命名规范：

1.test目录下测试文件名同源码文件名同名，后缀以.test.js结尾
2.test/unit和test/integration建立测试文件夹时，参照短横线（kabab-case）规范命名。
3.js和ts文件依照短横线（kabab-case）规范命名，Vue文件依照驼峰（camelCased）规范命名。
4.每一个源码文件（如js，ts，vue）对应一个同名.test.js文件。（index文件能够忽略）

3、编码原则

必须符合 BCDE 原则：

B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
C：Correct，正确的输入，并获得预期的结果。
D：Design，与设计文档相结合，来编写单元测试。
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务容许输入等），并获得预期的结果。

避免如下状况：

1）构造方法中作的事情过多。
2）存在过多的全局变量和静态方法。
3）存在过多的外部依赖。
4）存在过多的条件语句。

建议：

1.涉及到的某些扩展模块可使用mock模拟
2.测试用例不要使用@ignored或者被注释掉，切记切记。

如何编写更好的单元测试

原文连接：https://www.techug.com/post/19-unit-test-code-tips.html
单元测试在最近的工做中使用比较普遍，我已经收集了一些关于如何编写更好的测试类的准则，而且我已经尝试着坚持这些准则多年了。记住，编写糟糕的测试是在浪费时间，并会在之后形成更大的问题。因此最好把这些准则记在内心。

19条建议

1.不该该编写成功经过的单元测试-它们应该被写成不经过的。

能够在几分钟内让任何一组测试经过，但这只是在欺骗你本身。

2.测试类应该只测试一个功能。

你应该用一个功能去测试一个方法。不然，你会违反了单一职责原则。

3.测试类具有可读性。

确保测试类标有注释而且容易理解，就像其余的代码同样。

4.良好的命名规范。

再次测试时应该像其余代码同样-便于人们理解。

5.把断言从行为中分离出来。

你的断言应该用来检验结果，而不是执行逻辑操做的。

6.使用具体的输入。

不要使用任何的自动化测试数据来输入，像date()这些产生的数据会引入差别。

7.把测试类分类，放在不一样的地方。

从逻辑的角度看，当没有错误指向特定的问题时这更容易去查找。

8.好的测试都是一些独立的测试类。

你应该让测试类与其余的测试、环境设置等没有任何依赖。这利于建立多个测试点。

9.不要包含私有的方法。

他们都是一些具体的实现，不该该包含在单元测试里。

10.不要链接数据库或者数据源。

这是不靠谱的。由于你不能确保数据服务老是同样的而且可以建立测试点。

11.一个测试不要超过一个模拟(mock对象)。

咱们努力去消除错误和不一致性。

12.单元测试不是集成测试。

若是你想测试结果，不要使用单元测试。

13.测试必须具备肯定性。

你须要一个肯定的预测结果，因此，若是有时候测试经过了，可是不意味着完成测试了。

14.保持你的测试是幂等的。

你应该可以运行你的测试屡次而不改变它的输出结果，而且测试也不该该改变任何的数据或者添加任何东西。不管是运行一次仍是一百万次，它的效果都应该是同样的。

15.测试类一次仅测试一个类，测试方法一次仅测试一个方法。

组织方法可以在问题出现时检测出来，并帮你肯定测试依赖。

16.在你的测试里使用异常。

你在测试里会遇到异常，因此，请不要忽略它，要使用它。

17.不要使用你本身的测试类去测试第三方库的功能。

大多数好的库都应该有它们本身的测试，若是没考虑用mocks去产生一致性的结果的话。

18.限制规则。

当在一些规则下写测试时，记住你的限制和它们（最小和最大）设置成最大的一致性。

19.测试类不该该须要配置或者自定义安装。

你的测试类应该可以给任何人使用而且使它运行。“在个人机器上运行”不该该出如今这。

4、编码规范：

1.test对应每一个源码建立单元测试包

2.每一个npm包，都要添加descript,描述名为npm包名。

如descript("awp-lib-moment",()=>{});

3.需生成快照文件的单元测试，快照须要每次提交。

4.expect test('') 中描述的是调用和指望输出结果。

如test("Moment.format('yyyyMMdd HH:mm:ss','2019/07/09 17:41:01') 指望输出结果：20190709 17:41:01", () => {});

5.进行参数或属性校验。

校验包含正向和反向校验，即正确类型正确输出和异常类型返回异常信息等。
校验种类包含，参数个数、参数类型等。

6.测试要覆盖实现中的代码的各个分支

7.一个测试方法只测试一个方法，不测试私有方法

8.一个测试类只对应一个被测类.

9.测试用例的变量和方法都要有明确的含义

5、测试维度

编写单元测试，主要参考如下几个方面：
来源连接：https://blog.csdn.net/qq_36505948/article/details/82797240

1.接口功能性测试

接口功能的正确性,即保证接口可以被正常调用，并输出有效数据!
------------------> 是否被顺利调用
------------------> 参数是否符合预期

2.局部数据结构测试

保证数据结构的正确性
------------------> 变量是否有初始值或在某场景下是否有默认值
------------------> 变量是否溢出

3.边界条件测试

------------------> 变量无赋值(null)
------------------> 变量是数值或字符
------------------> 主要边界：最大值，最小值，无穷大
------------------> 溢出边界：在边界外面取值+/-1
------------------> 临近边界：在边界值以内取值+/-1
------------------> 字符串的边界，引用 "变量字符"的边界
------------------> 字符串的设置，空字符串
------------------> 字符串的应用长度测试
------------------> 空白集合
------------------> 目标集合的类型和应用边界
------------------> 集合的次序
------------------> 变量是规律的，测试无穷大的极限，无穷小的极限

4.全部独立代码测试

保证每一句代码，全部分支都测试完成，主要包括代码覆盖率，异常处理通路测试
------------------> 语句覆盖率：每一个语句都执行到了
------------------> 断定覆盖率：每一个分支都执行到了
------------------> 条件覆盖率：每一个条件都返回布尔
------------------> 路径覆盖率：每一个路径都覆盖到了

5.异常模块测试

后续处理模块测试:是否包闭当前异常或者对异常造成消化,是否影响结果!

6、测试目标

说明：如下仅做为参考，实际还须要按照各自项目进行评估。

语句覆盖率：>=70%

分支覆盖率：100%

函数覆盖率：100%

行覆盖率： >=80%

执行覆盖率, 业界标准一般在 80% 左右!!