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

[debugger0]

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

[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]

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