单元测试的爱恨情仇，作为码农们，你们写单元测试么？

[tikazyq]

作为从事软件开发多年的资深码农，看遍了各种事故和火葬现场。在接触测试驱动开发以及敏捷之后，发现这正是解决 bug 丛生、issue 漫天，最终导致 996 、007 修 bug 的困境。

这里将单元测试的一些看法分享给大家，希望能够提供一些启发。英译版同步发布在 dev.to，欢迎一起交流学习。

下面是正文。

---

浅谈测试：单元测试的爱恨情仇

引子

"开发安全可靠的应用程序的最好方式，就是不写代码。"--Kelsey Hightower

很多开发者应该或多或少听过单元测试（ Unit Tests ），甚至编写过，也或许对其有所了解。不过，在如今瞬息万变的环境下，单元测试似乎正在成为鸡肋。程序员们都知道它的好处，但是对其显得比较冷淡。“进度这么赶，还有什么时间写单元测试呢？”这样的话是不是听着很熟悉？

单元测试是什么？

所谓单元测试，简而言之就是程序员编写测试代码来验证自己写的功能代码是否能按照要求运行。如果测试代码不能通过，就说明自己写的功能代码是有问题的。

这种自己测自己的方式似乎有些可笑，相当于考试时看着答案做题。然而在测试领域，这样的方式有个专业术语叫白盒测试。而白盒测试的对立术语叫黑盒测试，也就是用其他方式来验证。单元测试属于白盒测试，而更高级的测试例如集成测试（ Integration Tests ）、端到端测试（ End to End Tests ）、UI 测试（ UI Tests ），都属于黑盒测试。单元测试仅仅是测试代码本身。

单元测试有什么用？

单元测试在敏捷开发（ Agile Development ）中是非常有用的工具。甚至有些敏捷框架，例如极限编程（ XP ），就要求每一个功能必须被单元测试覆盖。在之前的文章《浅谈敏捷：你的团队在正确实践敏捷吗？》就提到过单元测试的重要性。

概括来说，单元测试有下面几个重要作用：

• 可持续质量保证：单元测试能保证业务逻辑代码在经常性的被更改或重构之后不被破坏
• 自动化集成：单元测试一般可以集成到 CI/CD 中，当代码提交后自动触发
• 功能文档化：测试用例可以帮助新接触该代码的开发者熟悉代码的功能和验证条件

因此，表面上来看，单元测试对于软件开发来说会带来比较大的收益。

为什么不写单元测试？

单元测试可以提高我们的产品质量、测试效率，那为什么程序员还是不喜欢写单元测试呢？据 JetBrains 统计，被调查者中仅有 57% 要写单元测试，仅有 35% 会在大部分项目中实施自动化测试。

那么，为什么？有几个可能的主要原因：

• 工作量变多：“50 行代码的功能，要我写 100 行来测？不加班能完成？”
• 专业自信：“我一个资深程序员，写出来的程序怎么可能有 bug 呢？”
• 感觉不适用：“就这么几个页面，也需要写单元测试？”
• 有专人测试：“反正都有 QA 了，找他们来不就是找 bug 么？”

然而，这几个原因都经不起推敲：第一，长期来看自己修复 bug 写的代码量肯定远不止这么点；第二，不管是多么牛逼的程序员，代码写多了，根据大数定理，都会有失误的时候；第三，简单功能如果被引用多了，也会变得重要；第四，QA 的主要工作是保证整体质量，而单元测试是保证局部质量，缺陷部件组装出的产品会优质么？

变得有远见

其实，这里最主要的原因是思维模式，程序员大部分时候会站在个体的角度，思考短期的问题，从而忽略了长期的成本收益。作为一个合格的开发者，最主要目标是用最有效的方式开发出最大价值的功能。因此，单元测试在短时间内无法创造价值，从而被很多人忽视。

单元测试就像读书，短期内不能让人知识渊博、名利兼收，但长期来看是会有效果的。单元测试如果成为习惯或组织文化，就会更容易打造高质量产品和持续交付。要在团队中推广单元测试，需要更根本的流程，例如极限编程、测试驱动编程，或者更高决策者，例如 CTO 、架构师。

社区

如果您对笔者的文章感兴趣，可以加笔者微信 tikazyq1 并注明 "码之道"，笔者会将你拉入 "码之道" 交流群。

本篇文章英文版同步发布在 dev.to，技术分享无国界，欢迎大佬们指点。

[yagamil]

靠经验 ， 自己用 postman 测试

[marcong95]

同蹲一个前端单元测试项目开开眼。。。

[litmxs]

写
要求行覆盖率 80%以上，函数覆盖率 100%
单元测试写的比较完善的话，修改代码后跑一遍单元测试就能验证改动是否有问题

[anonydmer]

@hsuyeung 这个没有固定的模式，你这两种方法都很常见，选择自己认为合理的好维护的就可以。 比如你这个参数的逻辑要改的时候，可以很方便的先定位到对应的单元测试代码中去即可。 我个人一般喜欢把常规逻辑和边缘性的异常情况分开来成不同的方法写

[saberlong]

写框架，函数库，基础设施时写比较好。业务的话，业务复杂起来后，维护成本很高。比如测试用例的执行顺序变化和并发执行时，会导致新增单测在单跑时正确，全部一起跑时就可能有时正确有时错误，维护非常耗时间。

[hsuyeung]

@anonydmer 我自己目前也是更倾向于每种情况一个测试方法，这样每个测试方法很容易一眼看懂逻辑。但是这样没法直观地看到有哪些可能的情况（需要去把每个方法都看看）。所以有点纠结了。

[microxiaoxiao]

三天两头修改就别写了，前两天 BA 让修改个字符串大小写，下划线。自动化测试的姐姐一通抱怨。

[ericgui]

今天花了 30 分钟修了一个 bug ，花了 2.5 小时写 test case

因为一个时间有关的函数，本地机器和服务器机器不在一个时区，这就很傻逼

[jones2000]

单元测试还要开发写， 不是测试组写的吗

[GiftedJarvis]

之前的公司单元测试和集成测试都会写, 现在公司的屎山, 写测试太恶心了

[vivipure]

前端业务代码不写，组件库和 SDK 开发写

[Rooger]

- 最近也有想法，写一篇关于自己对单元测试的看法。无奈身体不适，暂时还没有动，所以先在此处写下自己的观点，但愿能帮助一些迷茫的同学。
- 简单介绍自己的经历，9 年游戏后端，开始用 C++，后面转 Go ，都没有意识到单元测试的重要性，直到去年看了一些博客和课程，才意识到单元测试的重要性。
- 我的结论是，后端服务单元测试一定要写，而且在时间允许（少摸点鱼）的情况下，一定要尽可能完善。
- 原因：
- 正常的逻辑经过通过正常逻辑的单元测试之后，可以避免前端同学人肉验证逻辑的正确性，好处是提高前端同学的对接体验，同时也给提高了后端人员的靠谱属性。
- 特别节省联调时间，前后端开发节奏并不一致，经过详细单元测试之后的逻辑，前端同学和测试测试极少出问题，并且不用打断后端的节奏，被打断的坏情绪会少很多。
- 适应频繁修改造成的不稳定性。看到有人抱怨需求频繁变更，就不想写单元测试了。这只是借口而已，正是因为频繁变动，才更需要。避免改动导致大面积逻辑异常真的可以依靠详细的单元测试。
- 节省后期维护成本，三个月甚至三年之后，你可能需要修改这段代码。如果有完整的单元测试，那绝对是相当舒服的一件事情。
- 最后补上一句，尊重自己，尊重这个行业。不管是自己维护，还是别人，都用心的去编码。即使是屎山，我也希望自己加进去的不是屎。

[charlie21]

开始写一些框架类代码的时候，才发觉 TDD 的好处

[YSMAN]

确实国内的环境 变化太快了 单元测试劳动成本 不可小视

[devHang]

写测试的好处在长期维护一个项目的时候才会体现出来。
TDD 是一个好的梳理代码逻辑的办法。
但如果不是自上而下的话，很难推动。

[jsjgjbzhang]

我想知道前端怎么写单元测试

[NoKey]

不写单元测试的原因，其实主要还是很多项目组或者公司不重视，或者，用人力去解决了。

安排工作量的时候，单元测试根本没有安排，实际工作已经满负荷了。

说白了，不写单元测试都 996 了，项目组或者公司根本没有考虑单元测试的时间。

强行加单元测试，就是 997 了

[micean]

月经贴吗
写 library 肯定要写单元测试，写业务不会写

[aviator]

做业务的写单测感觉会比写业务代码本身耗时还长

[bingoshe]

1.单元测试时间不够，取决于你的 leader ，你的 leader 当然会跟你说要写，但是不会给你时间
2.996/007 不是因为事情多，而是要对你精神控制