单元测试到底测什么，怎么测？我来告诉你

目录

前言：

单元测试并非测试的全部

边界环境的模拟

点到为止

总结：

前言：

以国内互联网的开发节奏，在前端业务项目中全面覆盖单元测试有时显得不太可行，主要是因为以下这些绊脚石：

• UI 交互复杂，路径难以覆盖全面
• 工期紧，开发对实践 TDD，BDD 所带来的长远效益没有信心
• 产品经理们时不时打着「敏捷开发」的旗号改需求，使得刚刚辛辛苦苦写完的测试脚本完全作废

在这样的处境下，一味强调单元测试的逻辑覆盖率是没有太大意义的，明确在哪里应用单测的能取得最大的边际效益是更有意义的事情。

以下笔者根据自己的一些在单测的实战经验，列出了三项关于「单元测试应该测什么」的观点并附以一些例子与大家交流：

单元测试并非测试的全部

拿来主义地对待单元测试

单测只是一种局部模块测试，是诸多测试方案中的一种，认识到这一点可以避免我们为了测试而测试，或者为了指标而测试。

同时也应该认识到单测本身的覆盖能力也是有限的，全部用例的 PASS 和 100% 的覆盖率都不能保证被测试模块的所有逻辑路径都有正确的行为。

是否对一个模块使用单元测试往往取决于这个模块的逻辑稳定性和业务类型

例如对于一个底层 npm 包项目，单元测试几乎是他唯一的代码质量保障手段，这时就应该尽可能通过单元测试验证它在各种应用场景下的行为是否符合预期，来最低成本地保证它每次发包和更新的质量。对这类项目，彻底应用 BDD 开发模式也会获得越来越高的开发效率收益。</