个人开发者写单元测试的人多吗？
source link: https://www.v2ex.com/t/926722
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
第 1 条附言 · 12 小时 56 分钟前
第 2 条附言 · 1 小时 21 分钟前
 |
wyl986 13 小时 42 分钟前 必写单元测试，必 100%。单元测试并不能保证极低的 bug 率（写的时候也确实能找到一点），对我而言，单元测试最大的目的是为了自己 /别人 n 年之后维护的时候能看懂写的啥，改了一个地方不至于导致其他的地方跑不起来。找 bug 还是要专门的测试来
|
1 |
ql562482472 13 小时 41 分钟前 我个人的问题是我不理解什么叫单元测试 测试类我是会写的，但是单不单元就很难说 都拆小方法了 写全乎 Mock 要写非常多
|
 |
kidult 13 小时 31 分钟前 更多时候是保证改动时的带来的影响，尤其是对于接手的人来说
|
 |
akring 13 小时 30 分钟前 对于没有 QA 兜底的个人开发者来说，单元测试是唯一的质量保障了
|
 |
LeegoYih 13 小时 26 分钟前 我一般写单元测试不保证覆盖 100%，主要是为了过冒烟测试。
保证无 BUG 还是要写一份测试用例，然后逐个测试，有改动需要对可能影响的范围进行回归测试。 |
 |
runinhard 13 小时 23 分钟前 单测对个人开发者来说主要意义 2 点：合理的代码设计（不至于无法或者不好写单测）；核心模块核心逻辑质量。
否则还是写 E2E 测试吧，性价比比较高。 |
 |
jsq2627 13 小时 10 分钟前 我倒是觉得恰恰相反
在公司写了无数单元测试后，给我的感觉是单元测试的意义，只有在别人也会参与修改同一份代码的时候有用，或者在依赖升级 green keeping 时候给人一点信心。 作为个人开发者独立开发项目的话，单测意义就体现不出来，而且还要花费大量时间维护单测（公司要求严格，平时写代码和写单测时间我感觉有 2:1 ）。而且作为个人项目，项目的生命周期可能还轮不到单测发挥意义就结束了。 |
 |
icyalala 12 小时 54 分钟前 @wyl986 100% coverage 很难搞，比如磁盘满了、内存分配失败了这类一般情况下不会出现的 branch 进不去，非要搞得 hook 系统函数。。
|
 |
JeffyChen 12 小时 48 分钟前 写 e2e 测试
|
 |
msg7086 12 小时 22 分钟前 我主要写集成测试。开发 SPA 比较多，所以针对 API 测。
|
 |
uiosun 12 小时 21 分钟前 路过，不写，只写接口测试。
WebServer 项目里，单元测试太费时间。 |
 |
enchilada2020 12 小时 19 分钟前 via Android 理智上是觉得需要的 这玩意跟注释同样重要
感情上是不爱写的 毕竟人都懒 |
 |
WngShhng 12 小时 9 分钟前 写单元测试+接口测试，算是一种保障应用质量的手段，而且从长远来看，下次改动的时候跑一下脚本就能确定改动是否影响原来的逻辑，好处还是挺多的
|
 |
Jammar 11 小时 57 分钟前 测试必写,但是只保证主流程,百分百覆盖太花费时间了,不值得
|
 |
beimenjun 11 小时 48 分钟前 个人理解：绝大多数项目没有 UT 的必要。
如果是个人做社区贡献，比如做基础组件、参与开源项目，受众不确定，那自然是有必要上 UT 的。毕竟开源项目很容易别人也要提代码，怎么确认代码能不能 merge ，很多时候 UT 绕不开的。 但如果是个人做一些面向大众的服务想要盈利，那投入时间之前得讲究投资回报比，因为时间不仅仅要做开发，还要做运营或者宣传的话，UT 个人觉得属于不太重要也不太紧急的部分，开发人员在一开始的时候保持一个比较好的状态和开发习惯并且避免摊子铺太大，可能对项目的质量影响更大，太早上 UT 是一种资源浪费，而且 UT 也完全可以等到真的盈利了再补。 当然如果是给别人做的话，看合同条款和个人偏好了。 |
 |
ivvei 11 小时 30 分钟前 不写，没什么意义。
|
 |
hhjswf 11 小时 2 分钟前 via Android bug 跟单不单测没直接关系呀，关键还是用例够不够完备，否则还是形式主义
|
 |
ssynhtn 10 小时 53 分钟前 via Android 根本就没人写单元测试
|
 |
xsen 10 小时 18 分钟前 按照经验（非中间件或基础组件），实际项目中大多数 bug 单元测试都无法测试出来
|
 |
n3r0 8 小时 20 分钟前 后端必写，前端可以交给用户测（逃
|
 |
TWorldIsNButThis 7 小时 51 分钟前 用空安全的语言，
用代数数据类型表达一个 model 的多态性而不是一股脑全可为 null ， 尽量写声明式而不是命令式代码， 尽量使用不可变变量， 尽量缩减变量的作用域， 尽量减少或者推迟副作用的出现， 减少数据竞争 代码上就这些了 最重要的还是业务要想清楚，大部分 bug 都是业务上没想到，代码写得再好也避免不了 |
 |
AoEiuV020CN 5 小时 57 分钟前 我个人项目只针对个别容易出问题或者容易不准确的算法写测试，
比如一些涉及到正则或者对比之类有规则正常使用只能覆盖部分场景的代码，就专门写个 unit test 测试正常不正常的数据， |
 |
weicools 5 小时 38 分钟前 我觉得还需要看看是什么类型的项目吧，前端，后端，客户端……
|
 |
8355 5 小时 10 分钟前 最开始我经理写单元测试和接口，后来我自己当负责人理解了我也写，其他人写业务代码。
这是最简单的方式保证团队代码产出的方式 可以保证基本的代码结构不会偏离你的最初设计同时可以一定程度上约束团队规范的执行 可以最快速了解你实际没有直接参与项目的代码结构 在长时间后再维护系统时单元测试代码可以快速梳理之前的代码功能和调用逻辑比看文档效率高得不知道多少 减少愚蠢问题导致的冒烟测试无法通过，可长期保持团队良好形象不被产品 /业务 /测试吐槽，只有我们喷别人的。 |
 |
debugger0 5 小时 3 分钟前 @TWorldIsNButThis #24 尽量使用不可变变量, 非常认同
|
 |
SuperMild 4 小时 16 分钟前 我写个人项目是为了快乐，单测带了的痛苦远大于快乐，因此决定不写。
有 bug ，宁愿辛苦点修 bug ，我感觉总体上修 bug 的时间比写单测的时间还要少很多。 |
 |
gzf6 4 小时 6 分钟前 业务没固定可以先不写
|
 |
matrix1010 3 小时 46 分钟前 看到很多回复感觉挺无奈，国内找工作写单元测试说不定都是减分项
|
 |
BeautifulSoap 2 小时 17 分钟前 公司项目写，个人项目随缘。公司项目的那业务单元测试复杂得，我现在看得都头大，不是工作真懒得去碰
|
 |
ixixi 2 小时 6 分钟前 简单的增删改查 不可能写的;
数据操作复杂的一般都会写 不然 f5 f5 f5 ..... ? |
 |
pengtdyd 2 小时 5 分钟前 不写！！！没必要，自己的项目可以全程把控，每一行代码我都知道自己的干了啥，这还写测试不是多此一举吗。
|
 |
streamrx 1 小时 45 分钟前 via iPhone 从来都不写
|
 |
Felldeadbird 1 小时 28 分钟前 个人项目不写，因为 BUG 来了马上发布新版就覆盖了。
想过写，可一个人精力有限，不如全力开发。 |
 |
Kaciras 1 小时 26 分钟前 API 稳定了就写，尽量全覆盖，可能有点完美主义吧
|
|
beimenjun 1 小时 11 分钟前 “是不是也有人一开始不写，到后面补上单元测试后，发现是真香的？”
感觉 OP 是想得到某种倾向的回答啊。 但是实际上，一开始不写必然有不写的理由，后面的收获也未必会影响之前的决策。 个人项目如果是做出来给其他人用的，先做出来，避免技术层面自嗨我觉得挺重要。 |
 |
SimonOne 46 分钟前 我的工作接触的是 sap abap 语言，我搞不懂什么是单元测试，为什么这么神奇能自动化测，我都是自己手动输入参数打断点直接测试的😓sap 似乎有看到过单元测试的功能，但大家好像都没用过。
|
 |
yuekcc 42 分钟前 只是为了交作业
|
 |
cutchop 10 分钟前 不用写了，等 copilot x 吧
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK