[科技知识] 为什么国内程序员不喜欢写单元测试？

天天财汇购物网址万年历小说 | 三峰软件小游戏视频

TxT小说阅读器
↓小说语音阅读,小说下载↓

一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓

图片批量下载器
↓批量下载图片,美女图库↓

图片自动播放器
↓图片自动播放,产品展示↓

首页淘股吧股票涨跌实时统计涨停板选股股票入门股票书籍股票问答分时图选股跌停板选股 K线图选股成交量选股 [平安银行]

股市论谈均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

商业财经科技知识汽车百科工程技术自然科学家居生活设计艺术财经视频游戏--

天天财汇 -> 科技知识 -> 为什么国内程序员不喜欢写单元测试？ -> 正文阅读

[科技知识]为什么国内程序员不喜欢写单元测试？

[收藏本文] 【下载本文】

为什么国内程序员不喜欢写单元测试？
关注问题?写回答
[img_log]
程序员
JavaScript 单元测试
单元测试
为什么国内程序员不喜欢写单元测试？

1、写了也不给钱
2、没人在乎软件质量
3、不懂编程也不在乎软件质量的人瞎指挥
4、其实绝大多数程序员也不会写单元测试
简单解释一下。
单元测试并不是你想象的那么简单：
见了：

int add(int x, int y);

于是你这样写单元测试：

int unit_test__add() {
   assertEQ(add(1,2), 3)
}

事实上，一个函数并不会天然的像上面那个add那么简单、无副作用的。这需要设计。
举例来说，你负责一个接口叫onNewOrder:

bool onNewOrder(order Order) {
    //一大堆乱七八糟的事
    //甚至可能包括更新用户在线状态你敢信?!
}

如果都到了临上线的前一天，order这个数据结构还在变，这个单元测试你写的了吗？
而且，如果它要求你更新用户在线状态、而更新在线状态居然没有抽象出来一个接口，而是要你这个顶层模块自己想办法更新底层模块的数据结构、而那个数据结构甚至都不在本地、同时也天天在变：这个单元测试又该怎么写？
更有甚者：

//没人知道order应该是个什么样的数据结构，甚至连优惠都需要你自己根据customerID自己查！
bool onNewOrder(int orderID, int[] productList, int[] buyNum, int[] price, int customerID)

这玩意儿的单元测试，又该怎么写？
所以，想要写单元测试，有一个前提条件。那就是先做好设计……
本系统总体分为三层。
最高层是业务层。本层控制订单的确立、支付和交付。
订单是如此定义的；涉及到的优惠卷、vip待遇等规则如此定义，共x类。
流程共分X步、Y个模块，模块接口是xxx、各自的任务是yyy、输出信息是zzz……
本层总体设计文档由xxx负责，x1、x2、x3协助。各模块设计文档分别由x1、x2、x3负责。
中间层是通讯层。本层负责解决高层各模块之间的通信需求。
报文类型有……定义为……控制流/数据流图如下……
底层为存储层。本层提供安全可靠、支持分布式事务的业务信息存储能力。
本层接口为……
你看，如果有这个设计，是不是单元测试就很容易写了？
某个模块还没开发完成？本地没有部署？没事，打个桩（stub[1]）就好了。
你甚至可以先写测试、后写代码，对吧。
相反……
甲，你负责订单。乙负责数据库。你俩多沟通。
啊，介绍一下，这是丙，他负责优惠卷、vip优惠等设计。你俩多和他沟通！
完了你们三个各自闷头写代码。写差不多了一碰头……完蛋，每个人的理解都不一样！
于是你们找经理解决。经理说哎呀你们怎么设计成这样了呢？不是的不是的，客户的需求是这样！
行了，遇到这种玩意儿……你就是神仙，有办法写单元测试？
还桩……你就装吧，哈哈哈。别人自己都不知道自己会写成什么样子呢，你怎么做桩函数？
你敢写，那你自己的设计一天三变，你就得付出成倍的精力才能维护好自己的函数代码以及对应的测试用例；而别人的设计呢……你瞎猜一个桩函数，估计人家应该这样设计，但人家就是不走寻常路——你是不是还得自己维护一份针对别人任务的设计文档、然后根据这个文档维护一堆桩函数：最后，当对方拿出自己不走寻常路的设计时，你是不是得把你猜想的设计文档以及相应的桩函数统统改掉？这个代价你承受的了吗？
更不要说有些神仙一个函数敢写成千上万行……单元测试[2]？哈哈。
参考^桩函数，指的是单元测试阶段，当前函数依赖的其他函数不存在或无法调用时，单元测试用例编写者自己写的一个无功能的替代品。作用是辅助绕过这个功能、完成针对待测函数本身的单元测试。^测试也是有一整套理论的。从各种覆盖到等价类划分等等，差不多也是一学期的课程或者说一本几百页的书。他连自己的老本行（结构化程序设计）都不会呢，你还指望他涉猎测试领域……
送礼物
还没有人送礼物，鼓励一下作者吧

因为写单元测试不算工作量，不参加考核。换句话，写单元测试没给钱。
实际上有很多开源代码有单元测试。因为他们代码本身就不是为KPI而写。
也有很多商业代码有单元测试，因为要么是真的给钱了。要么是领导有相关流程要求。
只要规定必须有单元测试才能交付，那么所有程序员都能写，这有啥难的呢。但如果项目组长，领导，产品经理，都觉得这个不重要，那自然就没人写了。
国外有些大公司，单元测试是代码不可分割的一部分，写了单元测试才能过code review。不会有那种「哎呀这个项目时间紧，单元测试就不用写了」的情况，自然大家都写。
单元测试必须成为固定的铁律，才会有人写。换句话说就是，天塌下来，没单元测试的代码也不能交付，项目组长，项目经理，相关领导都这么想，那么写单元测试就根本不是问题。。。
只要项目负责人会产生「项目时间紧，单元测试可以不写」这种想法，那么，以后可能就永远不会写单元测试了。

没有在真正意义上重测试的团队待过是不会知道原因的。
最大的问题是：当需求改动时，测试代码也要改。
所以，当你改需求时，首先你就要评估清楚所有用例的有效性——考虑到比较完善的测试覆盖率的话，这里需要评估的用例就不是小数目。
然后，你要改用例。考虑到很多用例流程大多是copy paste的，所以你会极为枯燥的去反复改类似的代码。那你要是说我也像功能代码一样，不允许用例的copy paste呢？那你就必须也弄一堆的封装和oop设计。但是很多用例平铺下来带来的逻辑清晰性就没了——然后你这时评估用例有效性就成了大麻烦了。
再接着，一个稍微有点规模的模块，几千几万个用例是起码的（例如说sqlite平均下来大约是1行代码对应1个用例）——这时候，你的用例的组织分类文档管理都必须花很大的精力。而且这也必须随着上面的需求更改->用例更改而跟随同步更改。否则，三五个版本迭代下来，你的这些东西就基本废了（因为活跃变动的需求才是大多数人关注的部分）。要管理好这些，要么专门开发定制一套工具，要么专门配个人（甚至是团队）来应付这些工作量。
最后，很多非功能性的优化，需求不变，但是因为内部逻辑变化可能会导致很多用例打桩方式失效。那么你的这些优化，如果是上级安排的，大家也都无话可说。但如果是程序员自己发现了个小优化点呢？随手就改了，就意味着你平白给测试人员增加了工作量。那么就上升到领导那里，然后走流程慢慢排期……我不知道别人是怎么看的，反正这样的团队我觉得技术氛围是很压抑的（如果抱着当一天和尚撞一天钟的想法，这样的团队倒还很适合）。
所以，重测试的前提就是需求和代码高度稳定。例如说华为搞通信设备起家的——交换机路由器防火墙的东西，从功能角度说，你的需求还想怎么变？到了后来换赛道了，emui之类的东西，就那bug的数量，鬼才信这些项目还在玩tdd。
国外的你觉得写测试多，那也是他们的软件的很多需求已经高度稳定都不怎么活跃开发了。像特斯拉自动驾驶之类的，看他尤其是早期的bug以及上市之后的bug收敛速度，我甚至都怀疑他有没有单元测试……

因为大多数人的项目不重要。
比如，你写了一个抽奖的页面。这个网页的整个生命周期里，可能都不会有超过1000人打开看过，点击抽奖的人更是不到100人。对于这种情况，写单元测试干啥？
其实，就算写了单元测试，意义也不大。自己写的代码自己测，能找出来的bug都是不重要的。
真正的单元测试，需要一整套工具链的配合，而这套工具链又得找个专人维护。
我以前在华为的时候，我们为通讯设备写C++代码，质量要求非常严格。提交的代码必须有单元测试，这个单元测试必须保证能覆盖到80%以上的代码，75%以上的分支。甚至每个函数的执行时间都有严格要求，里面使用的函数必须是安全的，你的代码还不能与别人的重复（连续4行一样就算重复）。导致我们上库的代码里面10行里有6行都是单元测试。这些都是硬指标，你提交代码以后，门禁系统自动跑验证，跑不过就不会走到codeview的流程。你得自己改。
我们在开发的过程中，并没有体会到这样写的好处，反而由于严格的门禁，使得开发效率变得非常低下。
直到，第一次上设备验证。
这里先补充一下，华为对于通讯设备的开发流程。
一般来说，硬件设备的开发和软件代码的编写是同步的。也就是说，软件代码在开发的时候，是没有硬件可以用的。此时，程序员的开发环境和生产环境是不一样的，写的代码也没有办法进行测试。但是，硬件设备的开发周期短则3个月，长则6个月。顺利的话，程序员会在4个月左右拿到硬件。在这4个月的内，程序员也不能闲着，就开始猛写代码，粗糙一点的情况，写的代码能编译通过就行，精致一点的话，隔一段时间还会把各个开发部门的代码同步一下。
这样的协作方式，必然导致第一版上硬件的那份代码100%让设备变砖。接下来就是程序员最苦逼的一段时间，每天在岗15小时以上，多个部门协作进行联调，短则15天，长则60天。最终会修改上千个bug才能使设备正常工作，但依旧不稳定。
话说回来。我们搞了严格的单元测试以后，把这个15天的联调周期缩短到了18个小时。这是管理团队最直接的体会。第一次尝到甜头以后，我那个部门对于单元测试要求就变得越来越严格。
后来，这份代码，用了多个工具进行检测。在公司内部还得了个“零缺陷”的表彰，部门主管还飞到各个研究所为大家分享经验。
主创人员和主管职级都飞升了。

通过长时间工作大家发现，测试点点点可以测出来95%的问题，写单元测试需要花费300%的时间解决99%的问题。
一个迭代周期大概是2周，晚上加班已经贡献给撸代码了。什么时间写单元测试？加人加预算谁又出这个钱？
但是不得不说，对日的客户（对接了好多项目了）宁可出钱，你也的把单元测试跟上+报告证明。他们很怕上线出问题，所以宁愿花1倍的支出保证安全。
所以说白了，能做单元测试的甲方。----财大气粗。

假设
你不写单元测试，上线时间一个月，后期修bug 半年。
写单元测试，上线时间三个月，后期修bug 一个月。
99%的项目经理或者老板会选择让你不写。
因为后期修bug时间是看不到的，但是上线时间慢是实实在在的。
随手写个回答，没想到评论区还真有几个强调低质量快速上线重要性的。
其实我懒得写的是，低质量代码能快速上线，往往只是项目经理和老板认为可以快速上线。
实际上没有单元测试的代码的项目，因为反复修bug延期上线的太多了。

为什么国内程序员不喜欢准点下班？
为什么国内程序员不喜欢晨跑锻炼？
为什么国内程序员不喜欢周末出去户外运动？
为什么... ...
你明明知道为什么，为什么还要问？

不知道为何半年后这个话题又有人来回复了。回答真的挺累的，我统一再说一下我的核心观点吧。
第O，我在华为工作时，我们团队是一个流程很严格，执行也很严格的。我相信华为大部分研发体系基本都如此。
第一，我没有说华为这样就是真理。
第二，我吐槽互联网公司执行流程就是瞎搞，项目倒排是常态，没有给开发时间，也更不会给测试时间。
第三，我没说互联网研发体系就得采用华为的流程。谁不懂很多时候项目的生命周期，紧急程度，并不适用冗长的流程。
第四，核心观点是，好的团队的是根据自己的业务特点，灵活制定流程，但是制定了，你就得执行。严格执行了，发现不合适的可以灵活调整。草台班子都是制定了一套严格的流程，从来不好好去执行。
第五，如果你要跟我讨论这就是敏捷，我懒得再打字了，看评论区吧。
第六，回归到这个题主的问题，为什么开发人员都不喜欢这单元测试。这表面是在吐槽开发职业素养不行，这句话背后实际在吐槽为什么从开发手里出来的代码质量这么差。我的回答没有任何吐槽开发的点。这种问题在任何一家不管大公司或者小公司，都是常年吐槽的问题。
第七，如果你要跟我说互联网的产品就是这样，快速，生民周期不一定长，那你不用打字说了，这种事干过一年研发体系的都懂。但为什么这个话题永远在讨论，永远在吐槽。很简单。因为我始终认为，这不是业务形态的问题，不是流程本身的问题，而是人的问题。最大问题出在研发管理者身上，因为他们不敢面对现实，不敢站出来说，我们当下就是这么奔放，我们就是要占领市场，我们可以暂时抛弃质量，我们就是没有足够的时间给到开发自测和测试迭代。如果管理者敢拍这个板，没有任何测试会纠结开发要不要做单元测试，专业的测试只会告诉你，这么多时间我能保证到什么程度，线上我评估会有什么风险。如果在这种场合下，测试做不到这种专业，那是测试的问题。而我认为现在的研发管理者，最大的问题就是，他们只知道去开发产品，根本就不懂研发流程。甚至不知道，什么流程适合自己的业务团队，只知道照搬照抄，然后出了问题甩锅打板子。再说华为，在华为干过都知道，华为的QA不是测试，是专门专业负责搞研发流程的。互联网现在叫PMO，但是我几乎没见过PMO有实际价值，都是出了故障来扯皮定责的。
第九，没看完，就不要评论了，没有新的观点，就不要评论了。评论了我不也回了不讨论了，好吧谢谢。
/* 以下是原回答 */
作为十几年的测试老兵，我可以很负责任的告诉你。我当年毕业进菊厂，经历的是非常严格和规范的研发流程，每个阶段转下个阶段，都是需要评审输出产物是否达标。TR4如果没有单元测试报告，集成测试报告，那不好意思了。转不了的。
后来在一线互联网大厂，流程形同虚设，项目都是倒排，而且绝大部分PM都极其不专业。他们认为测试的工作就是点点点，开发就是撸代码，什么架构设计，详细设计时间，不存在的，什么开发自测的时间，哦可能给你这么一丢丢吧，给到测试，什么设计测试用例的时间，不存在的。而在我看来，开发好好花时间做一份详细设计，测试好好做一份测试用例设计，才是最有价值的事。
我有时候挺理解为什么开发写的代码这么垃圾，因为说白了，大部分公司，都是草台班子。说到底互联网对质量的诉求几乎为0，或者只是嘴巴上说说重视罢了。

如果UT不算KPI，为啥要写？
如果UT算KPI，有什么不能写？
一直以来都不是技术问题，而是钱的问题。你想要更高质量的代码

对这个问题我有一个更离谱更嘴臭的见解：
相当多程序员不知道什么是单测，不知道该怎么写单测，写出来的所谓“单测”，先不说完全不能提升质量，这种所谓“单测”本身就是在给两个月后的自己喂的翔。
俺曾经以为的单测：
编写代码时，将外部依赖抽象为接口，运行时依赖注入；运行单测时，将依赖 mock，模拟依赖给出不同反馈的情况下，测试我这段代码的表现；测自己的代码，而不是测依赖；ut 中永远不访问真实的外部依赖；ut 作为“契约”存在，当某次变更后发现“契约”不满足了，重新 review 是我的变更产生了预料外的影响，还是“契约”需要更新了；
俺在大厂见到的“单测”：
核心思路只有一个底线：写了段测试，跑到了我的一部分新代码，在某个时刻、某个环境下跑通过一次，那这就是“高质量的 ut”；没有任何依赖抽象设计，代码直接依赖全局变量、单例；运行 ut 时，先 Init 全局变量和单例，然后就真的开始访问现实世界的资源了（下游服务、DB、在线配置），好一点的是访问的都是测试环境的资源，至少和生产环境隔离开；被依赖的全局变量和单例有状态，ut 一并发，只能祈祷上天这次要过，不能过就再祈祷一次，然后 rerun 看看；不怎么测自己，但一定把现实世界的依赖测满了，某天现实世界依赖挂了/改了/没了，那这段 ut 就落后版本了；换台机器 ut 就不能跑了，因为那台机器网络环境不一样，现实依赖连不上；因为依赖现实世界，对于现实世界无法模拟的分支条件，压根也就测不到；后续变更时发现 ut 彻底过不去了，那不用想，一定是 ut 落后，不满足我的船新版本了，所以要改 ut，让 ut 适应我的版本，或者太麻烦了，直接删了这段 ut 吧；
在“给两个月后的自己喂翔吃”这件事情上，聊什么 ROI、KPI、OKR、绩效都太抽象了，因为不管你要不要把拉翔和吃翔写进 OKR，不管写进 OKR 后要不要真的执行，去思考“为什么不喜欢吃翔”这个问题也还是太抽象了。
面对这些，我的状态也经历了：
啊？怎么他们好像都不太懂，要不要教教他们？怎么比我职级高的人，也拉翔给两个月后的自己吃？怎么有人给两个月后的自己喂翔吃，看起来还很自豪？写个文档分享一下吧，但是好像没人听，大家还是在拉翔给两个月后的自己吃。啊？哦。你们拉你们的吧，我肠胃不好，今天先不拉了，wish you have a good dinner。深夜睡不着的时候思考：虽然我一般不吃他们的翔，但天天看着也难受啊，怎么摆脱？深夜睡不着的时候复盘：是不是我面试、选择职位的过程有问题？我应该怎么改变我的择业方式，去没有人吃翔的地方？哎想不通。深夜睡不着的时候继续思考：中国人是不是人均房贷压力太大了？所以被迫吃翔？深夜睡不着的时候还是思考：不对啊这翔都是你们自己选择要拉给自己的啊？神奇的人类，好难理解。
这个见解适应面未知，但应当广泛存在，我每跳一家都会看见，我跳的还一直都是大厂，有时候我在想小厂有没有可能好一些，但目前没敢冒险。
国外的没太了解，但是从我不多的外企经历，以及一些和海外 base 的非国人同事合作的经历看，似乎海外整体是会好一些，他们可能写单测，可能不写，但一般不会拉保质期两个月的翔。

你算工时我就喜欢
你不算工时，急着明天就要上线，那就没人要写这玩意儿了。

从很多回答来看，大部分人压根没经过严格的ci/cd流程，对过程中ut的作用毫无概念，对常态化ut也没什么体验，纯粹把ut当功能测试/接口测试看待…
我要stop了，过去在国内的那几年就是很烦在一些基础概念和实践上跟一帮压根没做过的人扯来扯去。这就像跟一帮完全没规律健身过的人谈日常运动，这帮人说上班都累死了还运动个啥哦这种感觉，不去真的规律运动的话没法解释实际上每周运动两三次可以有效缓解上班疲劳——-这跟写ut一个道理。不过没做过就是没法解释。
*************
从评论看，我得纠正一个关键误区：写单测ut是要额外时间，但不是和业务代码量成线性比例的，通常是一个绝对值，例如两小时、半天或一天（8小时）。其实最多半天4小时就该足够了。花8小时那种是对刚接触项目的新人。
因为你写ut不是从头开始，也不是业务代码有多少行你就要“按比例”写多少行，你写1000行业务代码，现有的ut可能就已经cover 40%了，然后你再花半小时一小时加一点点，差不多就覆盖60%…毕竟虽然下面我说ut还是需要你熟悉代码架构,但归根到底还是就是调一下几个function…
当年某厂搞研效改革，争论不休说写ut会导致额外成本20%，30%，听起来似是而非，但是实际上不是的。ut的行数不少，但是写起来心智负担不大（相对于业务逻辑），而且就是初上手新项目的时侯花时间，熟悉之后很机械的操作，并不是固定要20%投入。
当然你说你业务代码已经几十万行，但是一个ut都没有，那是得花点时间写一下基本的，那也不过两三周了不起了，拿一个迭代时间，让高职级的搞搞，其实成本没那么大。实在觉得代码仓库太大，也可以从部分component开始做起，归根到底还是个习惯和意愿问题。
************
因为要ut发挥作用对技术要求其实非常高，不是你们想的跑一个function测一个输入输出就完事。不同覆盖率对技能的要求并不仅仅是多花点时间写，而是每个门槛都代表了不同技能和代码熟悉度的等级。不喜欢写一则是并没要求，二则是实际上有难度。
要达到50%左右覆盖率，只需要基本编程能力，对自己所写代码中没啥依赖的主要function调用一下就可以了。这意味着达到50%覆盖率，至少这个人的代码不是垃圾，应该是主要path和逻辑是还ok的。要达到这个目标，里面最大的坑通常也不过是重构下代码，把有依赖的一些提出去，把主要业务流程尽量包含在几个纯粹的函数中，这只需要普通初级程序员，对自己所写这个pr的代码逻辑熟悉，刚毕业的也可以。
代码覆盖率稳定达到70%或75%以上，这通常意味着这个pr的代码主要code path是没问题的，是可以接受的。这通常就需要开始mock各种dependency，如db/sever/某些外部class等等。其中有些可以直接mock，有些需要mock内部方法的返回，这就要求对业务数据有较多了解，实际上是用unit test方式来模拟关键业务流程。这一则很花时间，二则要能较快完成这个工作，需要的不仅是对自己所实现功能的了解，更需要对整个service数据流程和接口关系了解，才能快速合理去mock，另外mock工具合理使用也是个坑，初级程序员很可能在这方面被卡上三四天。
如果代码覆盖率稳定在80%或85%以上，这意味着这个pr的作者对相关业务逻辑和数据都有较好的理解。要达到这个目标，需要对整体业务代码架构逻辑、mock工具非常熟悉，因为这个覆盖率通常意味着不但要cover happy path，还有bad path，就要mock各种异常数据和抛出异常。而如果业务代码中包括了异步/并发处理，那么如何在ut稳定避免异步的干扰也是个影响稳定性的问题。还有到这个阶段，大量mock的数据在不同ut中很可能互相干扰，如何不过度设计但又较好的保持ut用数据和mock的清晰，也是要思考的事。通常要senior及以上才有较好的处理。这需要一定设计能力，不是说专门要为unit test去design什么框架，那也不至于，但是得靠你码农多年的经验让这个高覆盖率的一堆ut能长期稳定运行，而不是稍微有点变动就又要改，也别搞出一个超级庞大的pr出来显得你很菜的样子…
而随着各种开源工具的完善，业务代码可能越来越简单，但也造成mock越来越麻烦，你不得不去了解各个包/dependency的一些设计才行。写业务代码不一定需要了解底层架构，但要写较高覆盖率的ut，一定得把关键模块的上下游调用和data path都搞明白才行。
从测试角度来说，要保证代码的可靠性，70%覆盖率其实足够了。到80%以上实际上有倒逼开发者熟悉代码和整体架构的作用。
90%以上要求没见过，那是有病。

内地的草台管理团队，普遍跳过设计阶段，实行土法敏捷开发。你做好单元测试，一小时后就货不对板了。土法敏捷开发里，单元测试当然是不纳入OKR计算的。
【以下内容由大语言模型AI自动生成】
敏捷风云录·第一幕：草台班子，设计缺席
【幕启，舞台背景为一家略显拥挤的创业公司，墙上挂着褪色的“创新、协作、快速迭代”标语，桌上散落着各种零食和咖啡杯】
【旁白，用京片子，语调中带着几分调侃与无奈】
哎，说创业道创业，编程路上多奇遇。今儿个咱来唱一出，草台班子编新曲！
【场景一：团队集结，设计缺席】
（舞台上，四位程序员（甲、乙、丙、丁）穿着随意，有的穿着拖鞋，有的头发凌乱，脸上带着初出茅庐的青涩与不羁）
甲（程序员甲，手里拿着半块面包，边吃边说）：哎，兄弟们，这项目启动会咋连个设计师的影子都没见到呢？
乙（程序员乙，戴着旧旧的眼镜，眼镜腿还用胶带粘着，一脸疑惑）：设计师？咱这草台班子，还讲究啥设计师啊？能写代码就行，谁有空谁上！
（台下观众窃笑，气氛轻松，第一个包袱）
丙（程序员丙，摆弄着手里的键盘，好奇地问）：那咱这项目，连个UI设计都没有，用户咋用啊？
丁（程序员丁，手里拿着一块画板，自信满满）：怕啥！咱有“手绘UI”，我小学学过画画，我来画几个按钮，保证用户看不出差别！（第二个包袱，观众笑声）
（这时，老板（戊）匆匆上场，手里拿着一份皱巴巴的纸，神色紧张）
戊（老板，满脸焦急）：兄弟们，紧急通知！客户那边的需求又变了，咱们得赶紧调整方向！
甲（程序员甲，惊讶地张大嘴巴）：啥？需求又变了？这不是早上才定的吗？
戊（老板，尴尬地笑了笑）：哎呀，客户嘛，总是善变的。不过没事，咱们草台班子，讲究的是“随机应变”，赶紧改！
（观众笑声中带着几分嘲讽，第三个包袱）
【转折一：需求混乱，开发受阻】
乙（程序员乙，扶额叹息）：这下可好，连需求文档都没写全，咱们就要开始编码了。
丙（程序员丙，苦笑）：这叫啥？这叫“无头苍蝇式开发”，咱们得靠猜来交流了！
（观众笑声更盛，第四个包袱）
【转折二：内部争执，各抒己见】
（突然，丁与戊发生了争执）
丁（程序员丁，激动地挥舞着手里的画板）：老板，这需求根本不合理，咱们得跟客户沟通清楚！
戊（老板，不悦地皱起眉头）：沟通？客户就是上帝，上帝说啥就是啥，咱们得无条件服从！
（气氛突然紧张，观众屏息以待，第一个转折）
（经过短暂的沉默，甲站出来打圆场）
甲（程序员甲，缓和气氛）：算了算了，咱们还是先把需求理清楚，再开始开发吧。不然，到时候又是一锅乱炖，咱们可没那么多时间返工。
（乙、丙点头赞同，戊也勉强接受，气氛缓和）
【旁白】
草台班子虽简陋，却也透出真性情。
需求混乱就开发，团队争执显原形。
【幕落，观众掌声雷动，夹杂着更多的笑声和思考】
（幕落，灯光渐暗，舞台上留下四位程序员和老板忙碌的身影，以及那句褪色的标语“创新、协作、快速迭代”，在昏暗的灯光下显得格外醒目。）
敏捷风云录·第二幕：土法敏捷，漏洞百出
【幕启，舞台背景依然是那家简陋的创业公司，程序员们正埋头苦干，键盘敲击声、鼠标点击声此起彼伏，空气中弥漫着紧张而忙碌的气息】
【旁白，用京片子，语调中带着几分调侃与嘲讽】
哎，说开发道开发，草台路上多磨难。今儿个咱接着唱，土法敏捷笑料添！
【场景一：土法敏捷，进度飞快】
（舞台上，甲、乙、丙、丁四位程序员正紧张地编码，屏幕上代码飞快滚动，偶尔还能听到他们低声讨论的声音）
甲（程序员甲，眉头紧锁，手指在键盘上飞快敲击）：这需求改得真快，咱们得跟上节奏，用咱的“土法敏捷”来应对！
乙（程序员乙，戴着旧眼镜，眼镜后面的眼睛闪烁着狡黠的光芒）：怕啥！咱有“边写边改”的绝技，保证进度不掉队，还能顺便练练咱们的反应能力！
（观众笑声中带着几分嘲讽，第五个包袱）
丙（程序员丙，突然惊呼，手指着屏幕）：哎呀，这段代码咋跟之前写的冲突了？
丁（程序员丁，头也不抬，继续画着他的手绘UI）：没事，咱们有“补丁大法”，哪里不对补哪里，保证软件能跑起来就行！
（观众笑声更盛，第六个包袱）
【转折三：漏洞频现，测试无力】
（这时，测试员（己）匆匆上场，手里拿着一份测试报告，脸色凝重得仿佛能拧出水来）
己（测试员，焦急地挥舞着手里的测试报告）：兄弟们，出大事了！这版本漏洞多得数不清，根本没法上线！
甲（程序员甲，惊讶地抬起头）：啥？这么多漏洞？咱们不是都测过了吗？
己（测试员，无奈地叹了口气）：测是测了，但咱们这“肉眼测试法”，哪能发现这么多问题？再说，你们这代码改得也太快了，我刚测完一个地方，你们那边又改了！
（观众笑声中带着几分同情与嘲讽，第七个包袱）
【转折四：加班加点，漏洞难堵】
乙（程序员乙，挠头不已，手里的咖啡杯都快被捏碎了）：那现在咋办？总不能让客户看到这么多漏洞吧？
丙（程序员丙，苦笑不已，手指在键盘上无意识地敲打着）：还能咋办？咱们得赶紧加班加点，把这些漏洞都堵上！
（程序员们开始加班，舞台上灯光昏暗，只有电脑屏幕发出微弱的光，映照着他们疲惫而坚定的脸庞）
丁（程序员丁，放下画板，拿起键盘，加入了补漏洞的行列）：算了算了，我也来帮忙，咱们得赶在截止日期前交付，不然老板得骂死咱们！
（观众感受到程序员们的辛苦与无奈，气氛略显沉重，第四个转折）
【旁白】
土法敏捷虽快捷，漏洞频现难解决。
加班加点补漏洞，身心俱疲谁人知？
【幕落，观众掌声中带着几分同情与思考，舞台上留下四位程序员和测试员忙碌的身影，以及那句褪色的标语“创新、协作、快速迭代”，在昏暗的灯光下显得更加醒目。】
（幕落，灯光渐暗，舞台上的一切仿佛都静止了，只有那键盘敲击声和鼠标点击声还在耳边回荡，提醒着人们创业的艰辛与不易。）
敏捷风云录·第三幕：补丁大战，客户维权
【幕启，舞台背景依然是那家简陋的创业公司，程序员们围坐在电脑前，脸上带着疲惫与焦虑，空气中弥漫着紧张的气氛】
【旁白，用京片子，语调中带着几分调侃与同情】
哎，说补丁道补丁，草台路上多艰辛。今儿个咱继续唱，补丁大战笑料新！
【场景一：补丁大战，漏洞难除】
（舞台上，甲、乙、丙、丁四位程序员正忙着给软件打补丁，屏幕上代码和错误提示交替出现，仿佛在进行一场激烈的战斗）
甲（程序员甲，眉头紧锁，手指在键盘上飞快地敲击）：这漏洞咋这么多啊？咱们打得补丁都快赶上软件本身的大小了！
乙（程序员乙，戴着旧眼镜，眼镜后面的眼睛布满了血丝）：怕啥！咱有无限补丁法、灰度上线、持续集成，只要客户没发现，咱们就能一直打下去！
（观众笑声中带着几分嘲讽与无奈，第八个包袱）
丙（程序员丙，突然惊呼，手指着屏幕）：哎呀，这个漏洞咋又冒出来了？咱们不是刚打过补丁吗？
丁（程序员丁，放下手中的咖啡杯，无奈地叹了口气）：这软件就像是个漏水的桶，咱们打的补丁就像是堵漏的泥巴，根本不够用啊！
（观众笑声更盛，第九个包袱）
【转折五：客户维权，投诉不断】
（这时，老板戊拿着手机匆匆上场，脸上带着愤怒与无奈）
戊（老板，愤怒地挥舞着手机）：兄弟们，出大事了！客户那边投诉不断，说咱们的软件漏洞百出，根本无法使用！
甲（程序员甲，惊讶地抬起头）：啥？这怎么可能？咱们不是一直在打补丁吗？
戊（老板，无奈地叹了口气）：哎，客户说咱们的软件就像是个定时炸弹，随时都可能爆炸，他们要求退款并赔偿损失！
（程序员们面面相觑，脸上露出惊恐与无助的表情）
乙（程序员乙，声音颤抖）：那现在咋办？咱们总不能把辛苦开发的软件拱手让人吧？
丙（程序员丙，苦笑不已）：还能咋办？咱们得赶紧想个办法，平息客户的怒火！
【旁白】
补丁大战虽英勇，漏洞难除心惶恐。
客户维权声不断，内部反思寻出路。
【幕落，观众掌声中带着几分敬意与思考，舞台上留下四位程序员和老板围坐一起，脸上带着坚定的表情，仿佛已经找到了解决问题的方向。】
（幕落，灯光渐暗，舞台上的一切仿佛都静止了，只有那坚定的目光和紧握的拳头还在诉说着他们不屈的精神和坚定的信念。）

因为这个世界就是一个草台班子。
上面的CEO一换，你们团队做了半年的APP可能就会直接砍掉。
明明说好是这样的功能，客户一句话，就推翻重来。
其他破事耽误了开发进程，但是你的项目经理不管，就是要这周上线。
写着写着代码，可能忽然整个部门就被裁员了。
如果业务稳定，流程规范，岗位可靠，对自己有技术追求，当然是可以给自己的项目代码，写上单元测试，提高自己可靠交付的能力，减少测试和重构的风险。
单元测试的核心目的就是这两个：
快速局部验证各种单元的正常逻辑与边缘场景为重构提供一定的可靠性和兼容性验证
在正确的提示词使用之下，把源码和需求喂给GPT，写清楚使用一些技法（比如要求用 JUnit5 和 @ParameterizedTest），给一个参考例子，基本上可以快速出测试。
只要有需要，花时间做便是。
但在公司来说，没有业务和利润支撑的技术产品，一文不值。
哪怕它有着各种优雅的架构设计，有着完备的单元测试，有着美妙的实现逻辑，但是它没有业务和客户的话，对公司来说它就是狗屎。
哪怕它有着狗屎一样的结构，面条般的耦合，极其混乱且危险的设计，但是他能正常运行支撑业务和客户的话，对公司来说它就是黄金。
你不是面向对象的程序设计，你是面向老板的程序设计。
老板不重视单元测试，要么你听老板的。要么你想办法让老板重视单元测试，然后再听老板的去写单元测试。
写单元测试从来没有喜不喜欢一说，只是权衡利弊的选择。

送礼物
还没有人送礼物，鼓励一下作者吧

来个需求，正常做需十天。
领导给你压成5天，你苦口婆心要到了6天。
产品中途变更数个功能点，对此你已习惯，
测试工时不够需要你提前一天提测，你没有说话，都是公司底层，何必互相为难。
公司为了快速迭代，同时数个迭代重合着进行，你咬牙坚持。
开发过程中一半的时间把你调去排查case，梳理逻辑，修别人的bug，参与各种会议，还分给你个调研的任务，你焦头烂额，申请周末加班没批，你只能自愿加班。
最后一天下班前，你按时提测，可气还没松，领导给你排了个紧急需求，明天就要。
这时，产品又要改方案被你当面怼到了下个迭代。
你跑阳台抽烟的功夫看到网上有人问：
“为什么国内程序员不喜欢写单元测试？”

这么说吧，我写单元测试最积极的，是我自己的开源项目，很多工作代码第一，确实不好测试，第二，就这今天还说我太追求完美主义把我裁员了呢，凭啥啊我还给他补测试。

以前上班的时候，2个月的工作量，技术主管看了，直接给我压缩成一个月，前端小伙伴只有一个，我还得负责后台的前后端，自己一边写接口，一边写前端页面对接自己。
然后我那个月加班了100个小时，周六全天加班，还写单元测试？我写尼……
最后赶进度出来的当然是bug满天飞，项目要上线的时候，整个部门加班到两点。
一番辛苦之后……项目总算上线了。
结果过了两天，老板说：不要了。
项目下线。
然后，老板心血来潮——那个好像不错。
接着立项。
又是我负责……
我TM在这个公司已经做死了三个项目。
送礼物
还没有人送礼物，鼓励一下作者吧

大家老说AI写代码不靠谱，不过这个场合刚好是让它大显身手的地方。
无论是Copilot还是gpt，写起单测来那真是得心应手，什么边界条件分支覆盖统统给你填上，偶尔有些地方它写的不对自己改改就行，一百行代码能给你瞬间生成五百行单测，这生产力还要啥自行车。

意识和能力的问题。
1、写不出单元测试，意味着结构大概率很有问题
2、没有 “最大的成本，是变更不经意间带来的副作用” 这个意识
3、估算时间的时候，只考虑编码的时间，也没有把测试的时间计算在内
最后一个就是大环境，在一个团队里头，只有你一个写单元测试，作用就是0，因为你压根挡不住别人在挖坑，你填的不够挖得快。
送礼物
还没有人送礼物，鼓励一下作者吧

我个人觉得有点形式主义害死人。很多公司，team或者码农，都不把unit test当test。
就算unit test写的再全，还是有人要integration，regression test，甚至写unit test从某种意义上只能增加自己和同事写代码的顺畅程度，却既得不到team内的credit，而且还天天帮不愿意写ut的peers擦屁股。
unit test本身的code的质量极度没讲究，最多最多为了一些line coverage而kpi式写……
前段时间跟一个同事讨教了非常多写ut的姿势，确实也是有很有质量追求的人，但是说到底还是氛围太差了……

重要的事情只说一遍:不要为业务逻辑写单元测试，否则你就得为单元测试写单元测试。

一是公司不给写单元测试的时间，二是程序员本身没意识到单元测试的意义，三是当前阶段整个程序员的圈子对单元测试的重视程度都不是很高。
首先，公司安排需求开发时是一般都只给需求实现本身的时间，而不会给额外的写单元测试的时间。有些单元测试写起来还挺繁琐的，需要的时间比需求本身的时间更多，一般人都会认为单元测试的时间花得不值。
其次，很多程序员本身也没有意识到单元测试的意义。包括我自己，进入大厂以后，刚开始的leader对单元测试也没有什么意识，我自己慢慢摸索和体验过一段时间，才慢慢推广起来。
真正让我觉得单元测试有用的，是看了leveldb的代码，leveldb包含了非常完善的单元测试，在学习它的代码的时候，几乎可以随意重构它的代码，重构完毕之后运行单元测试，只要能通过，就表示重构OK。
再次，整个程序员的圈子，包括各种论坛，对单元测试的讨论氛围都不是很浓厚，所以不会引起大家的重视。新手程序员很喜欢把屎山挂在嘴上，鄙视这鄙视那。我觉得没有单元测试的代码，写得再好看，也是屎山。因为维护麻烦，重构代价大。
既然是没有氛围，公司也不给时间，那只能靠自己了。就像我，为什么要写单元测试，因为我是实打实地体会到了单元测试的作用，很多时候写代码会变得轻松，尤其是一些边界情况，边写边测，感觉脑细胞都不怎么使用的。而单元测试更大的意义，当然是对于代码的维护和重构，相当于为代码的整个生命周期保驾护航。
送礼物
还没有人送礼物，鼓励一下作者吧

我很多年前，在微软公司和爱立信公司都干过这种活。还是外包工作。而且工资还挺高。
按照微软和爱立信领导的说法就是：
这些公司太大了。软件功能出一点错，就上新闻。为了以防万一，必须做单元测试。说好听叫流程规范，说难听的就是甩锅，就是每一个函数和功能都做了测试，出了错不怪开发人员。怪测试人员没测试出来。
我干了半年多就不干了。因为，这个项目交货以后，只要有问题，都算在测试人员头上。扣测试人员的绩效。和开发人员无关。
因为，我连这些函数是干什么的都不清楚，业务也不知道。只能按照之前其他模块的单元测试照猫画虎。单元测试的代码基本上就是上坟烧报纸。

忙着敏捷开发上线呢，哪有空给你写单元测试？
送礼物
还没有人送礼物，鼓励一下作者吧

兄弟们大清国亡了可以自动化生成单元测试了。
应对喜欢单元测试的领导贼好用。
程序员的政治斗争我最擅长了。
送礼物
还没有人送礼物，鼓励一下作者吧

[收藏本文] 【下载本文】

科技知识最新文章

百度为什么越来越垃圾了?

为什么程序员总是发现不了自己的Bug?

出现在抖音评论区里边的算命真不真？

你认为 C++ 最不应该存在的特性是什么？

为什么 Windows 的兼容性这么强大，到底用了

如何看待Nvidia禁止使用翻译工具将cuda运行

为何苹果搞了十年的汽车还是难产，小米很快

该不该和AI说谢谢?

为什么突破性的技术总是最先发生在西方？

加:2025-05-14 13:27:13 更:2025-05-14 14:09:22

股票涨跌实时统计涨停板选股分时图选股跌停板选股 K线图选股成交量选股均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

网站联系: qq:121756557 email:121756557@qq.com 天天财汇