个人开发者写单元测试的人多吗？

[debugger0]

写了单元测试的话，覆盖率有多少？如果单元测试覆盖率 100%的话，基本可以保证极低的线上 bug 量吗？

如果不写单元测试，还有什么方法降低 bug 的数量？各位大佬是如何保证软件的健硕性的

看了留言，大部分是倾向于不写单元测试的，是不是也有人一开始不写，到后面补上单元测试后，发现是真香的？

[wyl986]

必写单元测试，必 100%。单元测试并不能保证极低的 bug 率（写的时候也确实能找到一点），对我而言，单元测试最大的目的是为了自己 /别人 n 年之后维护的时候能看懂写的啥，改了一个地方不至于导致其他的地方跑不起来。找 bug 还是要专门的测试来

[ql562482472]

我个人的问题是我不理解什么叫单元测试 测试类我是会写的，但是单不单元就很难说 都拆小方法了 写全乎 Mock 要写非常多

[kidult]

更多时候是保证改动时的带来的影响，尤其是对于接手的人来说

[akring]

对于没有 QA 兜底的个人开发者来说，单元测试是唯一的质量保障了

[LeegoYih]

我一般写单元测试不保证覆盖 100%，主要是为了过冒烟测试。
保证无 BUG 还是要写一份测试用例，然后逐个测试，有改动需要对可能影响的范围进行回归测试。

[runinhard]

单测对个人开发者来说主要意义 2 点：合理的代码设计（不至于无法或者不好写单测）；核心模块核心逻辑质量。

否则还是写 E2E 测试吧，性价比比较高。

[zhuzhibin]

@runinhard 别把，维护成本高啊，如果业务迭代快的话，可想而知

[jsq2627]

我倒是觉得恰恰相反
在公司写了无数单元测试后，给我的感觉是单元测试的意义，只有在别人也会参与修改同一份代码的时候有用，或者在依赖升级 green keeping 时候给人一点信心。
作为个人开发者独立开发项目的话，单测意义就体现不出来，而且还要花费大量时间维护单测（公司要求严格，平时写代码和写单测时间我感觉有 2:1 ）。而且作为个人项目，项目的生命周期可能还轮不到单测发挥意义就结束了。

[icyalala]

@wyl986 100% coverage 很难搞，比如磁盘满了、内存分配失败了这类一般情况下不会出现的 branch 进不去，非要搞得 hook 系统函数。。

[JeffyChen]

写 e2e 测试

[runinhard]

@zhuzhibin 迭代快啥成本都高啊。

[msg7086]

我主要写集成测试。开发 SPA 比较多，所以针对 API 测。

[uiosun]

路过，不写，只写接口测试。

WebServer 项目里，单元测试太费时间。

[enchilada2020]

理智上是觉得需要的 这玩意跟注释同样重要
感情上是不爱写的 毕竟人都懒

[WngShhng]

写单元测试+接口测试，算是一种保障应用质量的手段，而且从长远来看，下次改动的时候跑一下脚本就能确定改动是否影响原来的逻辑，好处还是挺多的

[Jammar]

测试必写,但是只保证主流程,百分百覆盖太花费时间了,不值得

[beimenjun]

个人理解：绝大多数项目没有 UT 的必要。

如果是个人做社区贡献，比如做基础组件、参与开源项目，受众不确定，那自然是有必要上 UT 的。毕竟开源项目很容易别人也要提代码，怎么确认代码能不能 merge ，很多时候 UT 绕不开的。

但如果是个人做一些面向大众的服务想要盈利，那投入时间之前得讲究投资回报比，因为时间不仅仅要做开发，还要做运营或者宣传的话，UT 个人觉得属于不太重要也不太紧急的部分，开发人员在一开始的时候保持一个比较好的状态和开发习惯并且避免摊子铺太大，可能对项目的质量影响更大，太早上 UT 是一种资源浪费，而且 UT 也完全可以等到真的盈利了再补。

当然如果是给别人做的话，看合同条款和个人偏好了。

[ivvei]

不写，没什么意义。

[hhjswf]

bug 跟单不单测没直接关系呀，关键还是用例够不够完备，否则还是形式主义

[kx5d62Jn1J9MjoXP]

根本就没人写单元测试

[xsen]

按照经验（非中间件或基础组件），实际项目中大多数 bug 单元测试都无法测试出来

[n3r0]

后端必写，前端可以交给用户测（逃

[mmdsun]

@n3r0 后端可以让前端测 ，前端让用户测

[TWorldIsNButThis]

用空安全的语言，
用代数数据类型表达一个 model 的多态性而不是一股脑全可为 null ，
尽量写声明式而不是命令式代码，
尽量使用不可变变量，
尽量缩减变量的作用域，
尽量减少或者推迟副作用的出现，
减少数据竞争
代码上就这些了

最重要的还是业务要想清楚，大部分 bug 都是业务上没想到，代码写得再好也避免不了

[AoEiuV020CN]

我个人项目只针对个别容易出问题或者容易不准确的算法写测试，
比如一些涉及到正则或者对比之类有规则正常使用只能覆盖部分场景的代码，就专门写个 unit test 测试正常不正常的数据，

[weicools]

我觉得还需要看看是什么类型的项目吧，前端，后端，客户端……

[Pythondr]

现在可以交给 chatGPT 写了
https://www.codium.ai

[8355]

最开始我经理写单元测试和接口，后来我自己当负责人理解了我也写，其他人写业务代码。

这是最简单的方式保证团队代码产出的方式
可以保证基本的代码结构不会偏离你的最初设计同时可以一定程度上约束团队规范的执行
可以最快速了解你实际没有直接参与项目的代码结构
在长时间后再维护系统时单元测试代码可以快速梳理之前的代码功能和调用逻辑比看文档效率高得不知道多少
减少愚蠢问题导致的冒烟测试无法通过，可长期保持团队良好形象不被产品 /业务 /测试吐槽，只有我们喷别人的。

[debugger0]

@TWorldIsNButThis #24 尽量使用不可变变量, 非常认同

[SuperMild]

我写个人项目是为了快乐，单测带了的痛苦远大于快乐，因此决定不写。

有 bug ，宁愿辛苦点修 bug ，我感觉总体上修 bug 的时间比写单测的时间还要少很多。

[gzf6]

业务没固定可以先不写

[matrix1010]

看到很多回复感觉挺无奈，国内找工作写单元测试说不定都是减分项

[BeautifulSoap]

公司项目写，个人项目随缘。公司项目的那业务单元测试复杂得，我现在看得都头大，不是工作真懒得去碰

[ixixi]

简单的增删改查 不可能写的;
数据操作复杂的一般都会写 不然 f5 f5 f5 ..... ?

[pengtdyd]

不写！！！没必要，自己的项目可以全程把控，每一行代码我都知道自己的干了啥，这还写测试不是多此一举吗。

[streamrx]

从来都不写

[Felldeadbird]

个人项目不写，因为 BUG 来了马上发布新版就覆盖了。

想过写，可一个人精力有限，不如全力开发。

[Kaciras]

API 稳定了就写，尽量全覆盖，可能有点完美主义吧

[beimenjun]

“是不是也有人一开始不写，到后面补上单元测试后，发现是真香的？”

感觉 OP 是想得到某种倾向的回答啊。

但是实际上，一开始不写必然有不写的理由，后面的收获也未必会影响之前的决策。

个人项目如果是做出来给其他人用的，先做出来，避免技术层面自嗨我觉得挺重要。

[SimonOne]

我的工作接触的是 sap abap 语言，我搞不懂什么是单元测试，为什么这么神奇能自动化测，我都是自己手动输入参数打断点直接测试的😓sap 似乎有看到过单元测试的功能，但大家好像都没用过。

[yuekcc]

只是为了交作业

[cutchop]

不用写了，等 copilot x 吧

[debugger0]

@beimenjun #39 是有这种倾向，最近有几次上线应用后才发现 bug ，最近正在恶补 UT 中。。。

[bugmakerxs]

写个啥，一把梭

[beimenjun]

@debugger0 我觉得这种事没啥必要找认同。

如果你用例设计不好，UT 100% 覆盖也没啥意义。而且出 bug 的原因可能有很多，而这里面缺少 UT 未必是最需要背锅的。

[mstmdev]

对于个人开发的项目还是会尽量去写一些单元测试，确保每一次提交没有打破原先的约定或者重复踩到相同的 bug 。而且个人开发者精力有限，每个修改没法回归测试整个流程，单元测试也是一定的质量保障。

想要追求 100%的覆盖率比较难，而且所谓的 100%覆盖率其实并不会覆盖所有的场景，100%覆盖率只是覆盖了所有的条件分支，但是并没法覆盖所有的分支的组合场景，最好再辅助一些常见场景的集成测试。

另外想要达到 100%的覆盖率必定要写一些 mock ，我的个人项目中曾经为了追求 100%的测试覆盖率，写了一堆 mock 的测试，一开始还好，随着代码量的增加，首先导致了测试代码难以阅读，其次很多 mock 的单元测试回过头来看几乎没有太大意义，脱离了实际的场景，并且很多涉及 mock 的测试几乎无法让其失败，仅仅成了一个形式，最终我删除了这些过度 mock 的单元测试，仅仅保持一定比例的覆盖率，不一定追求 100%，但是尽量保持代码的可维护性和可阅读性

[frankies]

我先说我的：单测是个什么玩意，没听说过。
个人项目说实话，从没写过。

[kemble7654]

@Pythondr 期待 java

[darlinghsu]

没事儿 github copilot X 快出来了哈哈哈

[debugger0]

@mstmdev #46 确实每个修改都做回归测试是不现实的，写了单元测试的话，每次发版前执行一个命令就把测试跑完了，软件质量有了保证，也节省了大量测试的时间

[pheyer]

个人觉得现在有了 GPT 工具，写单元测试更容易了，只是代码有泄密的风险😂

[coolmenu]

马上就能自动生成单元测试了。。。

[sdjl]

一般情况下不写，因为写单元测试浪费时间，如果有比较好的代码基本功，写代码有一定的规范，通常小项目并不需要写单元测试。

但是，如果涉及到金钱，例如订单、退款、付款等，这些代码要写单元测试，并且要尽量覆盖各种可能性。我写的代码之前有 3000 多万的交易，几乎没有出过问题，靠的就是单元测试。

[sdjl]

@darlinghsu copilot X 现在可以用了吗？ 我还在用 copilot

[icyalala]

@cutchop 我觉得用 Copilot X 你反而可能要去专职写 test ，毕竟代码可以生成，但对不对就就不知道了

[uni]

如果是自己的正式项目的话一定会写

[janus77]

写什么写，一把梭，能跑起来就别改，除非有人提 bug 。bug 是改不完的，不提就别动他。
可以借助一些静态代码扫描稍微提升一下健壮性，但是测试真没必要
当然这是针对 op 说的个人项目

[jones2000]

个人项目不写单元测试。 再说了，不是所有程序都可以写单元测试的。我是做前端绘图的， 比如我写了一个在画布上绘制一条线段的方法， 我应该怎么写单元测试， 验证画布上画的线段颜色点位是正确， 基本就靠肉眼看了。