1. 自己动手编写测试

1.1. QA团队可以帮助你验证你的代码是否稳定，但千万不要把代码直接丢给他们，然后让他们做所有的测试

1.2. 避免硬编码的值，不要重复代码

1.3. 专注于测试基本功能而不是实现细节，这有助于代码库的重构

1.3.1. 测试代码在重构后仍然可以运行

1.4. 将测试的依赖项与常规代码的依赖项分开

2. 避免过度测试

2.1. 要编写那些在测试失败的时候有意义的测试，不要为了提高代码覆盖率而去提高代码覆盖率

2.1.1. 测试数据库包装器、第三方类库或基本的变量赋值，即使它们能提高覆盖率指标，也是毫无价值的

2.1.2. 要专注于那些对代码风险有最大影响的测试

2.2. 将代码覆盖率作为一个指南，而不是硬性的规则

2.2.1. 高的代码覆盖率并不能保证正确性

2.3. 不要为自动生成的代码手动编写测试

2.3.1. Web框架

2.3.2. 脚手架

2.3.3. OpenAPI客户端

2.4. 代码生成器是经过彻底测试的，所以测试自动生成的代码是在浪费时间

2.4.1. 除非你手动引入对生成文件的修改，在这种情况下，你应该测试它们

2.5. 把精力集中在最高价值的测试上

2.5.1. 测试需要时间来编写和维护

2.5.2. 专注于高价值的测试，可以产生最大的收益

2.5.2.1. 首先应该关注代码中的高风险的区域

2.5.2.2. 那些低风险或被废弃的代码并不值得测试

3. 测试中的确定性

3.1. 确定性的代码对于相同的输入总是给予相同的输出

3.2. 非确定性的代码对于相同的输入可以返回不同的结果

3.2.1. 一个需要在网络套接字上调用远程网络服务的单元测试具有不确定性

3.2.1.1. 如果网络出现问题，那么测试也会失败

3.2.2. 测试中的不确定性降低了测试的价值

3.3. 间歇性的测试失败（被称为拍打测试）是很难重现和调试的

3.3.1. 它们不会在每次运行时都复现

3.3.2. 你不知道问题是出在测试本身还是你的代码上

3.3.3. 拍打测试的结果不能提供有意义的信息，开发人员可能会忽略它们，并因此提交错误的代码

3.3.4. 间歇性失败的测试应该被禁用或立即修复

3.4. 非确定性通常是由对休眠、超时和生成随机数的不恰当处理引入的

3.4.1. 测试中遗留下来的副作用或与远程系统交互也会导致非确定性

3.5. 种子随机数生成器

3.5.1. 随机数生成器(random number generators，RNG)必须使用一个值作为种子，这个值决定了你从它那里获取的随机数

3.5.2. 可用一个常数作为随机数生成器的种子，迫使它每次运行时都能确定地生成相同的序列

3.5.2.1. 使用常数种子的随机数生成器的测试将总是通过或总是失败

3.6. 不要在单元测试中调用远程系统

3.6.1. 远程系统的调用需要网络跳转，这是不稳定的

3.6.2. 避免远程调用也能保持单元测试的快捷和可移植性

3.6.3. 通过使用模拟库或重构代码来剔除单元测试中的远程系统调用，从而使远程系统仅在集成测试中被需要

3.7. 采用注入式时间戳

3.7.1. 如果处理不当，依赖于特定时间间隔的代码会导致非确定性

3.7.2. 使用静态的系统时钟方法，如now或sleep，则表明你的代码依赖于时间

3.7.3. 可以使用注入式时间戳而不是静态时间方法，这样你就可以控制你的代码在测试中获取的时间

3.7.3.1. 注入式时间戳将让你使用模拟来精确控制测试中的时间流逝

3.8. 避免使用休眠和超时

3.9. 记得关闭网络套接字和文件句柄

3.9.1. 许多测试都会泄露操作系统的资源，因为开发人员认为测试是短暂的，当测试终止时，操作系统自己会清理一切

3.9.2. 泄露的资源会导致不确定性

3.9.3. 操作系统对打开的套接字和文件句柄的数量有一个上限，当有太多的资源被泄露时，操作系统就会开始拒绝新的请求

3.10. 绑定到0端口

3.10.1. 测试不应该绑定到某个特定的网络端口

3.10.2. 绑定静态端口会导致不确定性

3.10.2.1. 在一台计算机上运行良好的测试在另一台计算机上会失败，只是因为端口被占用了

3.10.3. 将所有测试都绑定到同一端口是一种常见的做法

3.10.3.1. 这些测试在串行时会运转良好，但是在并行时就会失败

3.10.3.2. 测试失败将是不确定的，因为测试并不总以相同的顺序执行

3.10.4. 将网络套接字都绑定到0端口，这将使操作系统需要自动去选择一个开放的端口

3.10.4.1. 测试可以检索被选中的端口，并在该项测试的剩余部分使用这个端口

3.11. 生成唯一的文件路径和数据库位置

3.11.1. 测试不应该写入某一个已经被静态定义好了的位置

3.11.2. 数据的持久性与网络端口绑定有同样的困境

3.11.3. 恒定的文件路径和数据库位置会导致测试之间相互干扰

3.11.4. 应该动态地生成唯一的文件名、目录路径以及数据库或表名

3.11.4.1. 动态ID可以让测试并行执行，因为它们都会读写到各自的位置

3.12. 隔离并清理剩余的测试状态

3.12.1. 不清理测试状态会导致不确定性

3.12.2. 无论你的测试是否通过，你都必须重置状态，不要让失败的测试“留下残渣”

3.13. 不要依赖测试顺序

3.13.1. 测试不应该依赖于特定的执行顺序

3.13.2. 在每次运行之间重置状态，将防止测试在状态发生突变时相互破坏

526互联

读程序员的README笔记07_测试（下）

1. 自己动手编写测试

1.1. QA团队可以帮助你验证你的代码是否稳定，但千万不要把代码直接丢给他们，然后让他们做所有的测试

1.2. 避免硬编码的值，不要重复代码

1.3. 专注于测试基本功能而不是实现细节，这有助于代码库的重构

1.3.1. 测试代码在重构后仍然可以运行

1.4. 将测试的依赖项与常规代码的依赖项分开

2. 避免过度测试

2.1. 要编写那些在测试失败的时候有意义的测试，不要为了提高代码覆盖率而去提高代码覆盖率

2.1.1. 测试数据库包装器、第三方类库或基本的变量赋值，即使它们能提高覆盖率指标，也是毫无价值的

2.1.2. 要专注于那些对代码风险有最大影响的测试

2.2. 将代码覆盖率作为一个指南，而不是硬性的规则

2.2.1. 高的代码覆盖率并不能保证正确性

2.3. 不要为自动生成的代码手动编写测试

2.3.1. Web框架

2.3.2. 脚手架

2.3.3. OpenAPI客户端

2.4. 代码生成器是经过彻底测试的，所以测试自动生成的代码是在浪费时间

2.4.1. 除非你手动引入对生成文件的修改，在这种情况下，你应该测试它们

2.5. 把精力集中在最高价值的测试上

2.5.1. 测试需要时间来编写和维护

2.5.2. 专注于高价值的测试，可以产生最大的收益

2.5.2.1. 首先应该关注代码中的高风险的区域

2.5.2.2. 那些低风险或被废弃的代码并不值得测试

3. 测试中的确定性

3.1. 确定性的代码对于相同的输入总是给予相同的输出

3.2. 非确定性的代码对于相同的输入可以返回不同的结果

3.2.1. 一个需要在网络套接字上调用远程网络服务的单元测试具有不确定性

3.2.1.1. 如果网络出现问题，那么测试也会失败

3.2.2. 测试中的不确定性降低了测试的价值

3.3. 间歇性的测试失败（被称为拍打测试）是很难重现和调试的

3.3.1. 它们不会在每次运行时都复现

3.3.2. 你不知道问题是出在测试本身还是你的代码上

3.3.3. 拍打测试的结果不能提供有意义的信息，开发人员可能会忽略它们，并因此提交错误的代码

3.3.4. 间歇性失败的测试应该被禁用或立即修复

3.4. 非确定性通常是由对休眠、超时和生成随机数的不恰当处理引入的

3.4.1. 测试中遗留下来的副作用或与远程系统交互也会导致非确定性

3.5. 种子随机数生成器

3.5.1. 随机数生成器(random number generators，RNG)必须使用一个值作为种子，这个值决定了你从它那里获取的随机数

3.5.2. 可用一个常数作为随机数生成器的种子，迫使它每次运行时都能确定地生成相同的序列

3.5.2.1. 使用常数种子的随机数生成器的测试将总是通过或总是失败

3.6. 不要在单元测试中调用远程系统

3.6.1. 远程系统的调用需要网络跳转，这是不稳定的

3.6.2. 避免远程调用也能保持单元测试的快捷和可移植性

3.6.3. 通过使用模拟库或重构代码来剔除单元测试中的远程系统调用，从而使远程系统仅在集成测试中被需要

3.7. 采用注入式时间戳

3.7.1. 如果处理不当，依赖于特定时间间隔的代码会导致非确定性

3.7.2. 使用静态的系统时钟方法，如now或sleep，则表明你的代码依赖于时间

3.7.3. 可以使用注入式时间戳而不是静态时间方法，这样你就可以控制你的代码在测试中获取的时间

3.7.3.1. 注入式时间戳将让你使用模拟来精确控制测试中的时间流逝

3.8. 避免使用休眠和超时

3.9. 记得关闭网络套接字和文件句柄

3.9.1. 许多测试都会泄露操作系统的资源，因为开发人员认为测试是短暂的，当测试终止时，操作系统自己会清理一切

3.9.2. 泄露的资源会导致不确定性

3.9.3. 操作系统对打开的套接字和文件句柄的数量有一个上限，当有太多的资源被泄露时，操作系统就会开始拒绝新的请求

3.10. 绑定到0端口

3.10.1. 测试不应该绑定到某个特定的网络端口

3.10.2. 绑定静态端口会导致不确定性

3.10.2.1. 在一台计算机上运行良好的测试在另一台计算机上会失败，只是因为端口被占用了

3.10.3. 将所有测试都绑定到同一端口是一种常见的做法

3.10.3.1. 这些测试在串行时会运转良好，但是在并行时就会失败

3.10.3.2. 测试失败将是不确定的，因为测试并不总以相同的顺序执行

3.10.4. 将网络套接字都绑定到0端口，这将使操作系统需要自动去选择一个开放的端口

3.10.4.1. 测试可以检索被选中的端口，并在该项测试的剩余部分使用这个端口

3.11. 生成唯一的文件路径和数据库位置

3.11.1. 测试不应该写入某一个已经被静态定义好了的位置

3.11.2. 数据的持久性与网络端口绑定有同样的困境

3.11.3. 恒定的文件路径和数据库位置会导致测试之间相互干扰

3.11.4. 应该动态地生成唯一的文件名、目录路径以及数据库或表名

3.11.4.1. 动态ID可以让测试并行执行，因为它们都会读写到各自的位置

3.12. 隔离并清理剩余的测试状态

3.12.1. 不清理测试状态会导致不确定性

3.12.2. 无论你的测试是否通过，你都必须重置状态，不要让失败的测试“留下残渣”

3.13. 不要依赖测试顺序

3.13.1. 测试不应该依赖于特定的执行顺序

3.13.2. 在每次运行之间重置状态，将防止测试在状态发生突变时相互破坏