单元测试和代码质量没有必然联系。首先用例都是在白盒的前提下设计，为了刷覆盖率，有很多种办法可以很鸡贼地避开边界，流水账一样走一遍过场，把字面的覆盖率做得足够漂亮。一个团队里你不能保证每个人都会在写用例时尽心去考虑边界，总有人能糊弄出覆盖率达标的稀烂代码。但如此花费极大的时间代价去凑覆盖率，还有意义吗？

我呆过的一个 MNC 公司里很多印度团队，他们搞 pipeline 的漂亮花哨程度可以把上层哄得不要不要的，单元测试覆盖自然是完美级别的，还有各种自动集成测试。然而，服务上线以后会花样扑街，出错错到匪夷所思。经常在救火，但往往一波未平一波又起。到底是哪个环节出篓子了呢？单元测试 90%以上的代码仍然是把用户、内部用户当小白鼠，藏满各种地雷。

也许你有过体会，写单元测试过程中可以顺手解决掉几个低级错误。但基本上就到此为止了。很多设计上的问题、接口的问题、性能问题、安全问题、并发问题...，单元测试都无能为力，必须得靠人工的系统测试来暴露。所以，我们为什么又得花这么大的工作量去刷覆盖率呢？单元测试的另一个副作用是巩固强化了旧有的设计与实现，让决策人在决定是否重构时畏首畏尾，也让每一次的代码更改变得无比磨叽，强制加到构建过程里也会浪费更多的时间。

从个人经历来看，虽然只是有限的视角，但已经很明显的看到讽刺性的一幕：零单元测试的商业产品，稳定地运行在客户的环境里，缺陷率在可预期范围里。这里还包括电信级的设备。另一面是追求覆盖率的产品，都还没到客户手里，内部已经炸开花了，坑了内部合作的团队。因为伴随着单元测试的还有敏捷开发的其它要素，势必让依赖内部基础库的其它产品团队充当小白鼠。当然这并不是单元测试本身的锅，问题还是出在人身上。但单元测试充当了很鸡肋的角色。也许在某些关键的算法上，适合用单元测试去查瑕疵；而对于 CRUD 或者接口层面的代码，写单元测试纯粹是走形式。为什么要欺骗自己呢？