关于单元测试的讨论

什么是单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。

单元测试的作用

保证代码质量，在漫长的系统维护过程中保证系统稳定性。

单元测试的好处

• 通过先测试最小模块，保证最小模块的质量来最大保证系统质量。

• 为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。

• 编写单元测试将使我们从调用者观察、思考。特别是先写测试（Test First），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

• 单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

• 自动化的单元测试避免了代码出现回归，提交之前就自动执行测试，那提交上来的代码就是有正确的。

单元测试的目标

验证“自己写的一小段代码是不是符合设计逻辑的”。这“一小段代码”，就是所谓的“单元”。

单元测试应该由谁编写

开发人员自己。

单元测试往往从开发过程中就开始了，开发同学需要先用单元测试验过了自己写的新代码没有问题并且老代码也不会被影响才能提测，开发同学不能将满是bug的代码就丢给测试同学。

为什么单元测试难以落地

对单元测试的误解：

1. 单元测试的目标不明确。“压根就没搞明白要测试什么，保证什么东西是对的”。“保证代码都是正确的”这一句话，就如同“开发一个微信”，是一件不可能完成的任务。
2. 对单元测试工作量的低估。为了让 TestCase 发挥作用，让测试容易运行，可以隔离，可重复，稳定的跑，需要学习和实施的东西非常多，甚至不亚于功能开发本身。低估，尤其是 Leader 对单元测试的低估，都可能让它最后变成“面子工程”。
3. 心态上抵触。很多开发同学认为“测试就应该只让测试工程师负责的”而排斥这件事。

什么时候开始单元测试

随着不断的迭代，代码的组织才能慢慢优化和清晰，这些稳固的代码产生的接口、模型才有被测试保护的意义。

随着业务慢慢稳定，团队人数和用户量慢慢多起来后，对代码的修改会陷入巨大的痛苦和不安中，代码相关影响无法控制时，也很自然的需要一点一点的把最重要的、稳固的逻辑的测试补充上。

参考经验：

• 一个项目代码在不断迭代大概10个月后
• 或者团队技术人员已经超过5个人
• 或者活跃用户已经超过1万人

就必须有测试保护。如果用动态语言（js，python等）编写程序，因为没有编译器的保护，就更要写测试。

单元测试用例设计

任何一个单元测试都应该包含：

• 正常输入
  • 离散覆盖参数值域
• 边界输入
  • 空值验证
  • 零值验证
  • 最大值验证
• 非法输入
  • 入参数据类型非法
  • 内存溢出验证

单元测试的验证级别

网上大牛总结的。这个问题可以和上面的用例设计结合起来。

• Level 1：正常流程可用，即一个函数在输入正确的参数时，会有正确的输出
• Level 2：异常流程可抛出逻辑异常，即输入参数有误时，不能抛出系统异常，而是用自己定义的逻辑异常通知上层调用代码其错误之处
• Level 3：极端情况和边界数据可用，对输入参数的边界情况也要单独测试，确保输出是正确有效的
• Level 4：所有分支、循环的逻辑走通，不能有任何流程是测试不到的
• Level 5：输出数据的所有字段验证，对有复杂数据结构的输出，确保每个字段都是正确的

根据自己当时的情况判断做到哪一个级别。一般做到 Level 2 就已经能够发现大部分的问题。

单元测试的幂等性

对于单元测试来说，保证其幂等性非常重要。

幂等就是在相同输入的前提下，其输出结果不随时间而改变。

对测试友好的代码的话，则需要尽可能的写出各种纯函数，从而保证幂等性。

应该尽量保证除待验证的代码之外，所有的不纯的依赖都要尽量 mock，以实现测幂等。