单元测试有必要吗？

[RuLaiFo]

单元测试有必要吗？

我在现在的公司工作近半年了，公司的项目都需要写单元测试。但是写了这么久，感觉写单元测试费力不讨好，有时候写单元测试的时间大于写业务逻辑的时间，需要 mock 一大堆数据。要保证各种覆盖率，特别是分支覆盖率，需要覆盖到所写的每一个分支。

另外，大家写的单元测试质量参差不齐，因为感觉大家都是为了写测试而写测试，而不是真正的 tdd 。然而在迭代频繁，节奏紧凑的环境下，想要做到真正的 tdd ，还是有很大的难度的（个人觉得 tdd 实现需求会花更多的时间，可能是自己没正确认识和掌握 tdd?）。所以这就导致大家往往先去实现逻辑，再去写测试。

简而言之就是认为单元测试费时费力，又没有明显的收益，想请教一下大家怎么看待单元测试。

初次提问，如有不恰当的地方，请大家指出。

[newtype0092]

以前不怎么爱写，直接手动去测，什么 mock 之类的也都不用，就手动修改加注释掉不相关的逻辑，一次是挺快，反复测的时候这些零碎修改就很麻烦，得不停的 stash 和 copy paste 。后来直接写 unit test ，其实就是稍微花点时间把这些逻辑搞成能重复执行的，调试起来会方便不少。

方便反复测试调试其实并不是最重要的，单测最大的收益是可以改变你设计程序时的思考方式，先考虑输入输出，构思各种情况和边界 case ，把这些都落实成单测代码，这时再开始写功能代码，思路会更清晰，考虑的也更全面。很多时候一些混乱的逻辑都是因为一开始没搞清输入输出就着急下手导致的，这些就是导致 bug 的根源。

还有就是别觉得费力不讨好，能把单测写好把覆盖率拉满是很 NB 的技能，即使在现在的工作环境里不重要，但却是实打实加到你身上的技能点，以后肯定有很多产出质量大于数量的工作是需要这种技能的。很多人不是吐槽工作中什么都学不到么，其实就是没认识到很多东西的重要性觉得没必要。

[matrix1010]

其实我觉得所有代码都应该有测试，只是重要度低些的代码测一下功能正常就行，而重要度高的代码则要把各种情况都测一遍

[meeop]

我觉得作为程序员,理想情况,对代码质量有极致的要求,单元测试是重要和必须的,且必须覆盖 100%情况

但是,显然,做到上述完美单元测试是有巨大成本的
所以现实中,无非是一个取舍,质量要求越高,单元测试要求越高
反之代码不复杂,对错误容忍程度高,开发时间紧,那就不做或者少做单元测试

测试的意义就是减少 bug,只是一个方法,而不是法律

[meeop]

我还算在一个大厂,惭愧的说,从业至今很少写单测,也几乎没在项目里见过别人的单测,可能是我参与的项目不够重要
不过对于像数据库这种复杂且严谨,且基本是个单机服务的程序来说,单测显然是必须的

[h82258652]

15 楼说得太对了
无法写单元测试证明你的代码耦合度过高，无法 mock

楼主应该开心才对，小公司都不会给时间你写单元测试的，能跑（ 2 种意思）就行了

[MoYi123]

我是觉得简单的 crud 代码没什么必要写测试, 本来就是一个把输入参数拼成 sql 的逻辑, 数据库端也被 mock 了. 单元测试里只能去根据参数看 sql 有没有拼对, 感觉没有起到什么作用.
对于能抽象出一些纯函数的代码, 单元测试就用很大用处了.

[gageshan]

部门这个项目维护开发 6 年多了，两万多个 commit ，9700 多个 pr ，主要流程都有 ut 覆盖。每个 pr 要合入 master ，都必须跑一遍全部 ut 。

[ClericPy]

嫌麻烦就只写功能测试, 反正我已经被测试挡住无数次不向后兼容的 bug 了

看你项目 SLA 要求有多高了, 一般核心项目 coverage 再高都不过分, 毕竟现在大多数公司喜欢让你周五上线周六日免费加班, 测试越严格周六日上班几率越低

[fengpan567]

不写单元测试难道等着测试给你提 bug 么，嫌麻烦就不要追求覆盖率了，正常的分支能跑通就行

[otakustay]

问题可不就在“为了写测试而写测试，而不是真正的 tdd ”，那就应该去解决这个问题，而不是质疑单元测试有用没用吧

[lewinlan]

crud 业务代码硬要测试确实吃力不讨好，
我理解比较合理的实践是，不追求 100%覆盖，强迫自己划分边界，把抽象的东西提出来，再测，
100%覆盖并不就意味着没 bug 了

[hingbong]

工具类的话，还是很有必要的，业务部分就看情况吧

[searene]

如果你觉得单元测试太麻烦、需要很多 mock 工作的话，那么很有可能你的代码架构有问题。这句话很多人都说过，但到底什么样的代码架构才有利于单元测试却鲜有人提，我觉得具体可以看一下这本书，讲什么是好的单元测试，以及怎么设计代码架构才能从单元测试中获取最大的收益的，写得很好：

https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns-ebook/dp/B09782L692/ref=sr_1_1?keywords=unit+testing&link_code=qs&qid=1639290414&sr=8-1

[sagaxu]

单元测试就像 “规律作息，自律饮食”。
每个人都知道这个好，这个重要，但是实践嘛，有人做的很好，然而大部分人完全做不到。

[charlie21]

付钱了吗，付单元测试的钱了吗，先付再写，付了就得写

[timle1029]

会写，而且必须要写

Unit test 的覆盖率不过关 build 就直接 fail ，至于覆盖率要求多少基本就是组内自己决定了，大部分在 90%左右

[chenyu8674]

能够有效避免修改代码时脑子浆糊搞出的低级错误

[WilliamYang]

如果你的代码质量过硬，我觉得不写也没什么，否则等到测试来提 bugs ，感觉双方挺浪费时间的

[limao693]

项目流水线，会自动计算覆盖率，打不到 80%，直接无法各入。好处就是，可以随心所欲小范围的代码重构，只要保证 UT 通过

[pusidun]

1.单元测试不仅是开发的活，实际上迭代初期测试不需要转测时，就需要介入到测试样例的编写上。没完全按照敏捷那套来吧。
2.你觉得浪费时间写，实际上如果这个错误在系统测试，集成测试甚至灰度发布阶段发现了，排错和修复的成本会是前一个阶段的 10 倍