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

单元

覆盖率

测试

bug

58 条回复 • 2023-03-26 01:29:35 +08:00

1

wyl986

2023-03-24 09:26:40 +08:00

3

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

2

ql562482472

2023-03-24 09:27:24 +08:00

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

3

kidult

2023-03-24 09:37:31 +08:00

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

4

akring

2023-03-24 09:38:18 +08:00

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

5

LeegoYih

2023-03-24 09:42:13 +08:00

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

6

runinhard

2023-03-24 09:45:31 +08:00

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

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

7

zhuzhibin

2023-03-24 09:56:47 +08:00 via iPhone

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

8

jsq2627

2023-03-24 09:58:30 +08:00

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

9

icyalala

2023-03-24 10:13:55 +08:00

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

10

JeffyChen

2023-03-24 10:20:41 +08:00

写 e2e 测试

11

runinhard

2023-03-24 10:44:11 +08:00

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

12

msg7086

2023-03-24 10:46:48 +08:00

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

13

uiosun

2023-03-24 10:47:14 +08:00

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

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

14

enchilada2020

2023-03-24 10:49:35 +08:00 via Android

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

15

WngShhng

2023-03-24 10:59:21 +08:00

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

16

Jammar

2023-03-24 11:11:03 +08:00

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

17

beimenjun

2023-03-24 11:20:07 +08:00

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

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

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

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

18

ivvei

2023-03-24 11:38:07 +08:00

不写，没什么意义。

19

hhjswf

2023-03-24 12:06:19 +08:00 via Android

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

20

kx5d62Jn1J9MjoXP

2023-03-24 12:15:05 +08:00 via Android

根本就没人写单元测试

21

xsen

2023-03-24 12:50:10 +08:00

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

22

n3r0

2023-03-24 14:48:08 +08:00

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

23

mmdsun

2023-03-24 14:54:48 +08:00

2

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

24

TWorldIsNButThis

2023-03-24 15:17:31 +08:00

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

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

25

AoEiuV020CN

2023-03-24 17:11:31 +08:00

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

26

weicools

2023-03-24 17:30:41 +08:00

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

27

Pythondr

2023-03-24 17:56:41 +08:00

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

28

8355

2023-03-24 17:58:00 +08:00

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

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

29

debugger0

OP

2023-03-24 18:04:57 +08:00

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

30

SuperMild

2023-03-24 18:52:16 +08:00

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

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

31

gzf6

2023-03-24 19:02:18 +08:00

业务没固定可以先不写

32

matrix1010

2023-03-24 19:22:04 +08:00

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

33

BeautifulSoap

2023-03-24 20:51:40 +08:00

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

34

ixixi

2023-03-24 21:02:17 +08:00

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

35

pengtdyd

2023-03-24 21:02:57 +08:00

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

36

streamrx

2023-03-24 21:23:00 +08:00 via iPhone

从来都不写

37

Felldeadbird

2023-03-24 21:40:21 +08:00

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

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

38

Kaciras

2023-03-24 21:42:22 +08:00

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

39

beimenjun

2023-03-24 21:57:52 +08:00

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

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

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

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

40

SimonOne

2023-03-24 22:22:44 +08:00

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

41

yuekcc

2023-03-24 22:26:42 +08:00

只是为了交作业

42

cutchop

2023-03-24 22:58:17 +08:00

不用写了，等 copilot x 吧

43

debugger0

OP

2023-03-24 23:04:19 +08:00

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

44

bugmakerxs

2023-03-25 00:01:56 +08:00

写个啥，一把梭

45

beimenjun

2023-03-25 00:10:52 +08:00

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

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

46

mstmdev

2023-03-25 01:02:26 +08:00

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

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

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