国外对单元测试很看重，国内嘛 emmm

百分之八九十的公司不会写单元测试的，一是因为开发人员不稳定，换来换去，造成代码大家都不太理解，能运行就行了，写什么单元测试啊；二，单元测试增加工作量，收效不大，开发同学认为有 QA 呢，写它干嘛呢？三，单元测试没有使用场景，没有统一的流程去卡单元测试通过率，没有人检测单元测试写的质量，写不写无所谓。四，项目太紧张了，没有时间写！

写，有单元测试覆盖率要求。
还是有用，起码能提高开发的测试意识。

经历过的公司，一般基础组件类的（比如一些组件）会对单测有要求，因为你单测覆盖率都给不出来别人不敢用，而且这类无界面的组件不写单测更难测试。

而业务系统的比较少，因为比较难写（大部分业务系统因为历史原因欠债严重，核心逻辑很可能在一个一堆 if else 的上帝类里，写功能都难，单元测试就更难了），而且业务变化太快、有测试人员校验，从质量角度也没有非常强的必要写。

我们有单测覆盖率的要求，但我实际看了开发的代码也只是为了完成任务而做的测试。

本菜鸡入行时间较短，呆过的几个小公司没见过写单测的

感觉大多数公司，业务部门的节奏应该都很难维护一套稳定的单测，很多业务部门的专业测试团队连自己本身，都因为维护成本大、日常测试任务排期紧等原因，连最粗粒度的接口测试集合都维护不好，场景维护不全。这种的让研发团队在每个需求工期里排时间设计测试用例，维护粒度更细的单元测试就更不可能了。
工作中遇到的单测覆盖全面且稳定的项目，大多是没有专职测试的开源工程或者内部非业务服务。

即使阿里、百度、字节、腾讯等大厂，也不是全部团队都写单测的，所以【写单元测试的公司】在国内大概率会很少存在，写不写看的是【团队】维度。当然还是会有一些小而美的技术公司要求写单测，这里不讨论。

做事情都看收益，你一个天天迭代，代码变来变去的项目，写单测来干嘛？嫌竞争对手给你的时间太多了是吧 。除了程序员手痒自嗨，想不到其他原因。对于相对稳定的基础服务、基础组件，影响范围或质量要求特别高的模块，写单测是很合理的。