作为一个在这行摸爬滚打了快十年的老程序员，每次听到"单元测试"这四个字，我都忍不住长叹一口气。不是因为我不知道它的重要性，而是因为这背后隐藏着太多国内软件开发行业的无奈和现实。
今天就让我这个从机械专业转行，在三家上市公司都待过的老码农，跟大家聊聊为什么国内程序员普遍不爱写单元测试这个话题。相信我说的每一点，都会让你产生深深的共鸣。
一、管理层的短视：ROI看不见，单测就是浪费时间
我记得刚入行的时候，在某马做嵌入式开发。那时候我还是个愣头青，看了几本国外的编程书籍，满腔热血地想要在项目中引入单元测试。结果你猜怎么着？
我花了整整一个下午写了十几个测试用例，覆盖了一个核心模块的主要功能。当我兴致勃勃地跟项目经理汇报进度的时候，他直接就懵了：“你今天干了什么？写了这么多代码，功能呢？演示给我看看啊！”
当我解释这是单元测试，是为了保证代码质量的时候，他的表情我至今还记得清楚——就像看着一个不务正业的员工。“客户要的功能还没做完，你在这搞什么测试？这些代码客户能看到吗？能直接产生价值吗？”
这就是国内大部分管理层的现状。他们看到的只有immediate return，看不到长期的code quality带来的维护成本降低。在他们眼里，程序员的价值就是快速交付功能，至于后期的bug修复成本、维护难度，那都是"以后的事情"。
更要命的是，很多技术管理者本身就是从这种环境下成长起来的。他们自己当程序员的时候就没写过单元测试，现在当了leader，自然也不会要求下属写。这种恶性循环一代传一代，形成了一种"不写单测也能活"的企业文化。
我在第二家公司（一个世界500强外企）的时候，情况稍微好一些。但即使是这样的大公司，中国区的项目经理依然会在私下里跟我们说：“单元测试这个东西，老外那边要求的，你们写几个意思意思就行了，不要花太多时间。”
二、996的时间压力：哪有空写测试，功能都做不完
说到时间压力，这可能是最让我们这些一线程序员无奈的地方了。
我清楚地记得在某马的那段日子，每天早上9点到公司，晚上9点之前绝对不敢走。项目排期表密密麻麻，每个需求都卡得死死的。PM每天都在催进度，“这个功能什么时候能上线？”“客户那边在等，能不能加快点？”
在这种环境下，你让我写单元测试？开玩笑呢！
我算过一笔账，假设我写一个功能模块需要2天时间，如果要加上完整的单元测试，至少还需要额外的半天到一天时间。而且这还是在我对单元测试框架已经比较熟悉的情况下。如果是第一次接触，学习成本还要更高。
项目经理可不管你这些。他们只看结果：你说这个功能2天能完成，为什么现在要3天？客户在等着呢！
更残酷的是，当项目出现延期的时候，第一个被砍掉的就是"非必要"的环节。什么叫非必要？在管理层眼里，单元测试就是非必要的。客户能看到功能，看不到测试代码，所以测试代码就不重要。
这种逻辑听起来很荒谬，但在国内的软件公司里，这就是现实。我见过太多项目，开发阶段为了赶进度不写测试，结果到了测试阶段各种bug层出不穷，最后还是要程序员加班加点地修复。但管理层永远学不会这个教训，下个项目还是一样的套路。
三、技术债务的恶性循环：屎山代码怎么测试？
有一次，我接手了一个"历史遗留项目"。当我打开代码的那一刻，我真的怀疑人生了。
一个函数1000多行，变量命名全是拼音，逻辑嵌套深度超过8层，全局变量满天飞，没有任何注释。这种代码，你让我怎么写单元测试？
这就是国内很多公司面临的现实问题：大量的legacy code根本就不支持单元测试。这些代码通常具有以下特点：
高耦合度：一个函数调用了十几个其他函数，依赖了无数个全局变量。你想测试这个函数，就必须先搭建一个复杂的环境，初始化一大堆依赖。光是写测试环境的代码，就比写功能代码还要复杂。
不可预测性：函数的行为依赖于很多外部状态，相同的输入在不同时间调用可能产生不同的输出。这种情况下，你根本没法写稳定的测试用例。
副作用满天飞：一个看似简单的函数，可能会修改数据库、发送网络请求、写文件、修改全局变量。这种代码的单元测试基本上就是集成测试，根本谈不上"单元"二字。
更要命的是，当你想要重构这些代码，让它们变得可测试的时候，你又面临着巨大的风险。没有测试覆盖的代码，你敢大规模重构吗？但不重构，你又没法写测试。这就形成了一个死循环。
我记得有一次，我花了整整一个星期，才给一个300行的函数写出了基本可用的单元测试。为了做到这一点，我不得不mock掉十几个依赖，写了大量的setup和teardown代码。测试代码比被测试的代码还要复杂，维护成本更是高得离谱。
这种体验实在是太糟糕了，以至于很多程序员都对单元测试产生了心理阴影。他们会觉得：“单元测试就是这么复杂，这么难写，性价比这么低，还不如不写。”
四、教育体系的缺失：学校不教，公司不培训
说起教育，这可能是问题的根源所在。
我是机械专业毕业的，虽然后来转行做了嵌入式开发，但我接触过很多计算机专业出身的同事。让我惊讶的是，他们中的大部分人在大学期间都没有接受过系统的软件工程教育，更别说单元测试了。
国内的计算机教育更重视算法和理论，对于实际的工程实践关注度不够。学生们花大量时间学习数据结构、算法、操作系统原理，但很少有机会参与大型的软件项目，也很少接触到真正的软件工程实践。
我记得跟一个985计算机系毕业的同事聊天，他告诉我他们学校的毕业设计是做一个简单的管理系统。整个系统就几千行代码，一个人几个月就能完成。在这种规模的项目中，单元测试确实显得"多余"——代码少，逻辑简单，手工测试几遍就能保证质量。
但是到了实际工作中，面对的是几十万行、几百万行的代码库，涉及多人协作、持续集成、长期维护。这时候手工测试就显得捉襟见肘了，单元测试的价值才真正体现出来。但遗憾的是，很多程序员在学校里根本没有接触过这种规模的项目，自然也没有机会体验到单元测试的价值。
更糟糕的是，很多公司也不提供相关的培训。新员工入职之后，直接就被分配到项目组，跟着老员工学习。如果老员工本身就不写单元测试，那新员工自然也学不到。
我在某马的时候，公司倒是组织过几次技术分享，但关于单元测试的内容少之又少。偶尔有人提到，也都是一些概念性的介绍，没有实际的案例和练习。大家听完之后，依然不知道怎么在实际项目中应用。
五、工具链和基础设施的落后
工具的重要性往往被低估，但它确实是影响开发体验的关键因素。
在我早期的职业生涯中，我接触过很多"上古"的开发环境。Visual Studio 6.0、VC++ 2008、一些定制化的IDE，这些工具对单元测试的支持几乎为零。想要跑个单元测试，你得手动编译，手动链接，手动执行，结果还是在黑乎乎的控制台里显示。
即使是到了现在，很多公司的开发环境依然比较落后。我见过一些传统企业，还在使用老版本的开发工具，CI/CD流程不完善，甚至连版本控制都是在用SVN。在这种环境下，你想要建立一套完整的单元测试流程，困难重重。
更不用说一些特殊的领域了。嵌入式开发、桌面应用开发、游戏开发，这些领域的单元测试工具和框架都不如Web开发那么成熟。我在做嵌入式开发的时候，想要给单片机代码写单元测试，需要搭建模拟器环境，配置交叉编译工具链，工作量巨大。
反观国外的一些开发环境，IDE集成度很高，一键运行测试，实时查看覆盖率，测试结果可视化展示。这种体验差异是巨大的。当写单元测试变成一件麻烦事的时候，程序员自然就不愿意做了。
我记得第一次使用JetBrains的IDE写Java单元测试的时候，那种流畅的体验让我印象深刻。右键点击方法名，选择"Generate Test"，IDE自动创建测试类，生成测试方法框架，一键运行，结果实时显示。这种体验让写测试变成了一种享受，而不是负担。
但遗憾的是，很多国内公司出于成本考虑，不愿意投资这些"不直接产生价值"的工具。他们宁愿让程序员用免费的IDE，也不愿意花钱买更好的开发工具。
六、心态和认知的偏差：测试是QA的事
在很多国内公司，有一种根深蒂固的观念：开发负责写代码，测试负责找bug。这种职责分工看似合理，实际上造成了很多问题。
我遇到过很多程序员，他们觉得自己的工作就是实现功能，至于质量保证，那是QA团队的责任。"我把功能做出来就行了，有没有bug QA会告诉我的。"这种心态在国内非常普遍。
这种分工模式在小规模项目中可能还能work，但随着项目复杂度的增加，问题就暴露出来了。QA测试往往是黑盒测试，只能测试外部行为，无法深入到代码内部的逻辑细节。很多边界条件、异常分支，手工测试很难覆盖到。
而且，QA发现bug之后，程序员修复的成本是很高的。你需要重新理解当时的代码逻辑，定位问题原因，修改代码，重新编译部署。如果是在代码编写阶段就通过单元测试发现问题，修复成本要低得多。
但很多程序员没有意识到这一点。他们把单元测试看作是额外的负担，而不是提高效率的工具。这种认知偏差很难纠正，因为它涉及到整个团队的工作流程和文化。
我记得在一次技术讨论会上，有个同事说："我们公司有专门的测试团队，程序员还写什么单元测试？这不是重复劳动吗？"这种观点代表了很多人的想法。他们没有理解单元测试和集成测试、系统测试的区别，也没有认识到不同层次测试的价值。
更有甚者，一些程序员会觉得写单元测试是对自己技术水平的质疑。"我写的代码肯定没问题，为什么还要测试？"这种自信虽然可贵，但在复杂的软件系统中是非常危险的。人无完人，再厉害的程序员也会犯错，单元测试就是一道安全网。
七、客户需求和市场环境的影响
这一点可能很多人没有深入思考过，但客户需求和市场环境确实对开发实践产生了深远的影响。
国内的软件市场有一个特点：变化快。今天客户要这个功能，明天就可能要修改需求，后天又可能要完全推倒重来。在这种环境下，投入大量时间写单元测试似乎确实不太划算。
我在外企做汽车电子的时候，项目周期通常是2-3年，需求相对稳定。客户（主机厂）对质量要求极高，软件bug可能导致召回，成本巨大。在这种环境下，写单元测试是理所当然的，因为长期来看绝对是划算的。
但回到国内的互联网环境，产品迭代周期可能只有几周。用户需求变化很快，竞争激烈，"快速上线、快速试错"成了主流。在这种模式下，代码的生命周期很短，可能写完几个月就要重构或者废弃。花时间写单元测试的性价比确实不高。
而且，很多国内客户对软件质量的容忍度比较高。Web应用崩了可以重启，手机App有bug可以发补丁，用户一般不会因为软件质量问题就拒绝使用。这种市场环境没有给软件质量太大的压力。
相比之下，欧美市场对软件质量的要求更严格。用户对bug的容忍度低，法律法规对软件质量有明确要求，质量问题可能导致严重的法律后果。在这种环境下，单元测试就不是可选项，而是必需品。
这种差异不是技术问题，而是市场环境和商业模式的差异。要改变这种状况，需要整个行业生态的升级，不是一朝一夕能够解决的。
八、技术栈的选择：某些技术确实难测试
在我的职业生涯中，我接触过很多不同的技术栈，深刻体会到了技术选择对单元测试的影响。
嵌入式C语言开发：这是我最熟悉的领域。嵌入式C代码往往直接操作硬件寄存器，依赖具体的硬件环境。你想给一个读取GPIO状态的函数写单元测试，就必须模拟整个硬件环境，工作量巨大。而且很多嵌入式系统资源紧张，根本跑不起来单元测试框架。
传统的Windows桌面应用开发：使用MFC或者WinForm开发的应用，UI逻辑和业务逻辑往往耦合得很紧。一个按钮点击事件可能直接操作数据库，直接修改界面。这种代码的单元测试基本上就是噩梦。
某些Web框架：虽然现在的Web框架对测试支持都不错，但我接触过一些早期的框架，对依赖注入、模块化支持不好，写单元测试非常困难。
相比之下，一些现代的编程语言和框架天然就对单元测试友好。比如Go语言内置了testing包，写单元测试就像写普通代码一样简单。Spring框架提供了强大的依赖注入机制，mock各种依赖变得很容易。
技术栈的选择往往不是程序员能够决定的，而是由公司的历史包袱、技术储备、成本考量等因素决定的。如果你的技术栈本身就不支持单元测试，那再有写测试的意愿也无济于事。
我记得在某马的时候，我们用的是一个定制化的嵌入式操作系统，连标准的C库都不全，更别说单元测试框架了。想要写测试，得先移植测试框架，工作量比写业务代码还大。在这种情况下，不写单元测试就成了最"理性"的选择。
九、团队文化和同行压力
程序员是一个很有趣的群体，我们在技术上追求卓越，但在工作方式上往往随大流。如果整个团队都不写单元测试，那新来的程序员很快也会"入乡随俗"。
我见过一些刚毕业的程序员，在学校里接受过良好的软件工程教育，知道单元测试的重要性，也有写测试的意愿。但当他们进入团队，发现没有人写单元测试的时候，很快就会放弃这个习惯。
为什么？因为同行压力太大了。
如果你是团队里唯一写单元测试的人，你会面临各种质疑：
- “你写这么多测试代码干什么？浪费时间！”
- “其他人都不写测试，功能也做得好好的，你这是在显摆吗？”
- “你的开发速度怎么这么慢？别人两天能做完的功能，你要三天？”
这种压力是很难承受的，特别是对于刚入职的新人来说。他们往往会选择妥协，放弃写单元测试，融入团队的工作方式。
更糟糕的是，一些技术Leader本身就对单元测试持怀疑态度。我遇到过一个技术总监，他明确告诉团队：“单元测试这个东西，国外公司搞搞还行，我们中国公司要的是效率，不要在这些形式主义上浪费时间。”
这种观点从上往下传递，很快就会形成整个团队的共识。即使有个别程序员想要坚持写单元测试，也很难得到支持。
反过来，如果团队有良好的测试文化，情况就完全不同了。我在外企的时候，团队里有一个资深的架构师，他对代码质量要求很高，每次code review都会检查单元测试覆盖率。在他的影响下，整个团队都养成了写单元测试的习惯。
团队文化的力量是巨大的，它能够改变个人的行为习惯，甚至改变对技术实践的认知。要推广单元测试，不仅仅是技术问题，更是文化和管理问题。
十、成本收益的错误计算
很多人反对写单元测试的理由是"成本太高，收益不明显"。但我觉得这是对成本收益的错误计算。
短期成本 vs 长期收益
写单元测试确实需要额外的时间投入，这是显而易见的短期成本。但很多人忽略了长期的收益：
- 减少bug修复时间
- 降低回归测试成本
- 提高重构信心
- 改善代码设计
- 减少文档需求（测试就是最好的文档）
我做了一个粗略的计算：在我参与的项目中，平均每个bug从发现到修复需要半天时间，如果算上影响分析、回归测试、发布部署，总成本大概是一天。而写一个单元测试的时间通常是几十分钟到几小时。从纯数字上看，如果一个单元测试能够防止一个bug，那就已经回本了。
隐性成本的忽略
很多人只计算了写测试的直接时间成本，但忽略了不写测试的隐性成本：
- 每次修改代码都要手工回归测试
- 重构风险高，导致代码腐化
- 新人接手项目的学习成本
- 客户发现bug的声誉损失
这些隐性成本往往比写单元测试的成本更高，但因为分散在长期的开发过程中，不容易被察觉。
规模效应的误判
还有一个常见的误判是忽略了规模效应。在小项目中，单元测试的收益确实不明显，但随着项目规模的增长，收益会指数级增长。
一个10万行代码的项目，手工测试还是可行的。但一个100万行代码的项目，没有自动化测试基本上就是不可维护的。很多程序员的经验停留在小项目阶段，没有体验过大项目的复杂性，自然也感受不到单元测试的价值。
风险承担能力的差异
最后，还有一个关键因素是风险承担能力。在创业公司，快速试错可能比代码质量更重要，不写单元测试是理性的选择。但在大公司、传统企业，或者对稳定性要求很高的系统中，风险承担能力很低，单元测试就变得至关重要。
遗憾的是，很多程序员没有根据具体情况调整策略，而是一刀切地认为"单元测试没用"或者"单元测试必须写"。
十一、个人反思：我的单元测试之路
说了这么多行业的问题，我也想分享一下我个人的单元测试之路，希望能给大家一些启发。
初期的抵触
说实话，我最开始也是抵触单元测试的。刚从机械专业转行过来，光是学会写代码就已经很不容易了，还要学写测试？而且当时的开发环境确实不友好，写一个简单的测试需要配置一大堆东西。
记得第一次被要求写单元测试的时候，我花了整整两天时间，才搞明白怎么运行起来一个简单的测试用例。那种挫败感现在想起来还很深刻。
转折点
真正的转折点是在外企工作的那段经历。有一次，我需要修改一个核心模块的代码，这个模块已经运行了两年多，非常稳定。但是新的需求要求增加一些功能。
幸运的是，这个模块有完整的单元测试覆盖。我在修改代码的过程中，多次触发了测试失败，每次都能够快速定位到问题所在。最终，我成功完成了修改，而且没有引入任何新的bug。
那一刻，我真正理解了单元测试的价值。它不是负担，而是安全网。有了这个安全网，我可以更自信地修改代码，更放心地重构设计。
技能的提升
随着经验的积累，我发现写单元测试其实是提升编程技能的好方法。为了让代码可测试，你必须：
- 降低耦合度
- 明确接口定义
- 考虑边界条件
- 处理异常情况
这些都是写出高质量代码的基本要求。换句话说，可测试的代码往往就是好代码。
现在的实践
现在，我在自己的项目中都会坚持写单元测试。不是100%覆盖（那不现实），而是针对核心逻辑和复杂算法写测试。我发现这样做有几个好处：
- 开发过程中能够更早发现问题
- 重构的时候更有信心
- 代码结构更清晰
- 团队协作更顺畅
当然，我也不是教条主义者。在一些原型项目、一次性脚本中，我也不会强制要求写单元测试。关键是要根据具体情况做判断。
十二、破局之道：如何推广单元测试
虽然困难重重，但我相信单元测试在国内还是有推广价值的。关键是要找到合适的策略。
从小项目开始
不要一开始就想在大项目中推广单元测试，阻力太大。可以从新的小项目开始，验证价值，积累经验。当团队看到单元测试的实际效果之后，推广就会容易很多。
选择合适的技术栈
如果有技术选型的决定权，优先选择对单元测试友好的技术栈。现代的编程语言和框架对测试的支持都很好，学习成本不高。
关注ROI最高的部分
不要追求100%的测试覆盖率，重点关注核心逻辑、复杂算法、容易出错的部分。这些地方的单元测试ROI最高，最容易体现价值。
改善工具链
投资改善开发工具和基础设施。好的IDE、CI/CD流程、自动化工具能够大大降低写单元测试的成本，提升开发体验。
培训和文化建设
组织培训，分享最佳实践，建立代码规范。更重要的是，技术领导要以身作则，在代码审查中关注测试质量。
渐进式推进
不要期望一夜之间改变整个团队的习惯。可以先从新功能开始要求写测试，逐步提高覆盖率。关键是持续推进，不要半途而废。
量化收益
收集数据，量化单元测试带来的收益。比如bug修复时间的减少、回归测试时间的节省、代码质量指标的改善。有了数据支撑，说服管理层就容易多了。
十三、展望未来：AI时代的单元测试
最后，我想谈谈AI对单元测试的影响。随着AI技术的发展，我觉得单元测试的门槛会越来越低。
现在已经有一些AI工具能够自动生成单元测试代码。虽然生成的测试质量还不够高，但已经能够处理一些简单的场景。我相信随着技术的进步，AI生成的测试会越来越实用。
更重要的是，AI能够帮助我们分析代码，识别风险点，推荐测试策略。这些能力对于推广单元测试非常有价值。
当写单元测试变得像使用智能提示一样简单的时候，我相信会有更多的程序员愿意尝试。
结语：路漫漫其修远兮
写到这里，已经近万字了。回顾我这些年的经历，从抵触单元测试到拥抱单元测试，从个人实践到团队推广，我深深感受到这条路的漫长和艰难。
国内程序员不喜欢写单元测试，不是因为我们技术水平不够，也不是因为我们不够专业。而是因为我们面临的环境、压力、约束确实不一样。
但我相信，随着行业的成熟，技术的进步，以及新一代程序员的成长，这种状况会逐步改善。我们这一代人可能改变不了整个行业，但至少可以在自己的项目中、自己的团队中，播下质量的种子。
也许十年后，当我们回头看今天的讨论时，会觉得这些问题都不是问题。就像我们现在回头看十年前的开发方式，觉得不可思议一样。
技术在进步，行业在发展，我们程序员也在成长。相信未来会更好。
最后，如果你是一个还没有写过单元测试的程序员，我建议你找个周末，选一个小项目，试着写几个简单的测试用例。不要想太多，就当作学习新技能。也许你会发现，单元测试没有想象中那么可怕，甚至还挺有趣的。
如果你是技术管理者，请给你的团队一些空间和时间去探索单元测试。短期可能看不到明显的收益，但长期一定是值得的。
技术的路很长，我们一起慢慢走。
作为一个在这行摸爬滚打了近十年的老程序员，我见证了太多技术的兴衰和观念的变迁。单元测试也许只是其中一个小小的议题，但它反映的是我们对代码质量、工程实践、团队协作的理解。希望我的分享能够给你一些启发，也欢迎在评论区分享你的经历和观点。让我们一起推动这个行业变得更好。
另外，想进大厂的同学，一定要好好学算法，这是面试必备的。这里准备了一份 BAT 大佬总结的 LeetCode 刷题宝典，很多人靠它们进了大厂。
有收获？希望老铁们来个三连击，给更多的人看到这篇文章
推荐阅读：
欢迎关注我的博客：良许嵌入式教程网，满满都是干货！
共同學(xué)習(xí)，寫下你的評論
評論加載中...
作者其他優(yōu)質(zhì)文章
