工作学习---开发写单元测试的规范

一、测试用例的写作规范

• 用例结构简单明了

好的测试用例应该包括构造输入数据、调用北侧对象、结果检查啊三个部分。

• 用例实现指责单一

一个用例只测试一个场景，用例禁止使用switch、if/else，测试代码是测试业务逻辑，实现逻辑尽量简单。

• 用例键独立无耦合

测试用例之间相互调用，用例执行应该与顺序无关。

• 结果检查充分

必须使用assert来进行自动校验；结果检查应该高效，避免陷入过多的实现细节。

• 代码简洁无重复

及时重构测试代码，封装跨测试的复杂或 这冗余代码。

二、测试坏味道

测试代码在实现上也与业务代码一样，长期不惊醒债务清理，则会产生坏味道，需要及时清除。

2.1 永不失败的测试

永不失败的测试坏味道来源于当代码出问题时，测试结果仍然通过，不会给出相应的错误告警。

重构建议：使用正确的断言。

2.2 脆弱的测试

DT测试代码应该尽量避免依赖外部资源，因为外部依赖不仅会导致测试时间长，状态不可控，也会影响测试结果，导致测试结果不确定。

重构建议：

1. 用测试替身替换外部依赖，根据需要将其包装到适配层；
2. 对于需要持久化的集成测试，建议使用内存数据库，用干净的数据集。

2.3 过度断言

过度断言是指断言对于关注行为的细节，检查项太多太细，以至于测试变得非常脆弱，甚至影响了其他更重要的测试意图，偏离的原本的测试目标。

重构建议：

1. 基于测试的目的确定关键断言，识别无关紧要的细节并从测试中删除；
2. 拆分测试，不同的检查项放在不同的测试用例中。

2.4 测试用例相关影响

一个测试用例作为套件的一部分时可以通过，但是单独执行却失败；原因是部分测试用例依赖测试套中的另一个测试的执行或结果，如测试中修改了全局变量值导致用例间产生耦合。

重构建议：

让测试自行建立所需的上下文，不要依赖于之前运行的任何测试。

2.5 断言意图不明确（基本断言）

断言的意义不直观，测试意图被隐藏在一长串看上去无意义的单词或者数字背后，难以理解，难以判断断言使用的正确性。影响代码的可读性。

重构建议：

1. 去掉断言中的复杂逻辑，让检查更加直观；
2. 从测试框架中找到更简洁更好的方式来优化代码，使其更容易表达意图。

2.6 测试功能不单一（模糊测试）

在一种测试方法中，验证了太多功能或暴露了许多与实际测试不相关的细节。

重构建议：

1. 自动进行测试时，最好有一套独立的针对单一测试意图的测试用例，因为他们可以提供更好的缺陷定位。

2.7 条件测试逻辑

测试包含条件逻辑，该逻辑根据当前环境执行不同操作。

重构建议：

1. 通过将测试与测试自动化的任何依赖关系脱钩，可以最好地解决灵活测试，确保测试用例的确定性。