重新认识单元测试

单元测试是对系统中最小可测试单元的功能进行自动化测试，来验证代码功能是否符合预期。单元测试的意义虽说都很清楚，但是实际开发中写出真正有意义的单元测试并不多或者说并不那么容易，甚至很多项目是根本没有单元测试的，本文旨在让大家对单元测试有一个完整的认识。

实际开发中单元测试的困境

开发时间紧张，没有多余的时间来写单元测试
开发者写单测的意愿低，单测的意义认识不足
开发者认识知道单测的价值，但不懂得单元测试的规范，单测质量低。
代码可测试性差，单测困难

其实上面的问题笔者都遇到过，估计很多人都有类似的体会，也因为疏忽踩了一些坑。

老生常谈：为什么要写单元测试

单元测试的最大价值就是尽快发现错误，稍有开发经验的都有一个体会：发现bug的时间比用来修复的时间要长的多。
以笔者为例，曾经修改了一行代码，上线后貌似一切都正常，过了好几天有用户开始反馈问题，最后发现就是修改的那行代码导致在某个特殊的场景会有问题的。如果这个错误能在跑单元测试的时候定位到，问题就可以上线前消除掉，而且这个场景在单元测试的时候完全可以覆盖到，只是当时整个项目几乎没有单元测试，质量仅靠测试人员是不行的。
单元测试就是一个bug侦测器，是保证代码质量的一个很重要的手段。

你写的是单元测试吗

为了注入对象竟然启动了整个服务
依赖第三方服务，服务挂了，单元测试也跑不过了
测试用例相互影响
测试用例里用输出语句来人工验证结果
单元测试的强度不够，结果验证不够全面
单元测试的覆盖度不足，一些重要的场景没有覆盖到

单元测试规范

不依赖第三方环境和服务
如果单元测试有对外部环境(网络、服务、中间件)的依赖，那一旦依赖不稳定，就会造成单元测试的失败，影响持续集成和测试进度。
自动化
很多人在验证数据时喜欢用log或者打印语句输出内容，人工核对，这种单测不能暴漏错误，而且没法自动化就没法到持续集成，也就称不上单元测试。
确保所有测试都完成自动化，让它们自己检查自己的测试结果。
单元测试要有足够的强度
比如验证一条insert sql，不仅要验证是否成功执行，还要验证一下插入的数据是否符合预期。只有保证足够的强度，在代码发生变化后，单测才能尽可能发现问题。
测试用例之间要相互隔离
测试用例之间要相互独立，包括上下文环境独立、数据独立等，目的是避免测试用例的不稳定。
数据隔离
这就要求不要共用测试数据或测试数据要及时清除。
单元测试的速度要快
目的是为了尽快暴露问题，另外也可以避免持续集成的时间过长。这一条结合第一条，就要求将单测的外部依赖全部改成本地实现或者Mock。

不要追求面面俱到的单元测试

如果每个方法、每个场景我们都努力去写一个单元测试用例，你会发现这是一个相当庞大的代码量，甚至比要测试的代码还要多。如果我们这样要求自己，我想多数人心里是会有抵触的，而且实际的开发中也未必允许我们有充裕的时间来这样做。
单元测试的出发点是尽可能发现bug，我们要测试是你最担心的可能会出错的地方，抓住重点，测试收益反倒会事半功倍。
花合理时间抓出大多数bug好过穷尽一生抓出所有bug，也更符合实际的开发情况。

当然单元测试不是万能的，但是没有单元测试的代码裸奔是不行的。记住，单元测试是程序不可分割的一部分！

更多内容欢迎关注个人微信公众号，一起成长！