大家平时工作，会主动写单测吗？

不写，要些也用 ai 写

业务不写，infra 写

都是 TDD ，测试和代码同步完成。没测试我对自己代码是没自信的

工期不赶的情况下，会把核心功能做好单测，变更多的时候，跑一下单测，避免重复测试。
奈何最近一年的需求基本都是倒排的，就没写单测了... 全靠手工测试+肉眼 review 代码

要求 C1 覆盖，估算工时时，UT 这部分会专门拿出来算时间的。
意思也就是说：即使 C1 写一遍，没有任何问题，但是 UT 必须要有。

不写，有什么问题给客户测

公司流程要求写，单元测试是其中一项，没办法。还是看要求吧。
俗话说有几个程度猿愿意写测试的

测试好啊 写完可维护大大滴 后续修改跑测试很方便

用 AI 写

自己只测功能，不写单测（ golang/web ）

咋俩不会一个公司吧

自己负责的业务，使用量比较大的时候，会写完整的流程测试，不敢指望测试妹妹点点点了😅

UT FT 总得覆盖一个吧

一般复杂的我都是先写单元测试，然后贴到业务代码中两边同时测，比较快排查问题

我们要写 95%以上的测试覆盖率

核心的都写，不核心的不写

组里规范的氛围很好，我现在必写单测了

没法不写，做 infra 的

想写，有高质量单测教程推荐吗？

野路子开发，从来没写过测试，都是人肉测，有什么测试教程或者规范吗？像我做 web 端 3d 开发的，操作逻辑都是前端手动操作的，这种测试怎么模拟呢？

流程要求写就写，流程不要求就不写

如果我是定流程的那会要求写

不写测试 review 要被骂，不按规范来 /(ㄒoㄒ)/~~

AI 写的也算自己写的（狗头

当然是强制要求单测覆盖率

也是 80%，现在有 copilot 了

单测要写,但是有时候单测比较麻烦,比如依赖的微服务需要 mock 等,工作量很大

作为一个二道贩子，核心业务也是对接来的。没办法测。

强制新增 90%覆盖

不写代码都上不去。。。80%

单元测试还是相当重要的，推荐几本好书： https://zhuanlan.zhihu.com/p/591751476

写。

有现成的例子才写。自己不会去新搭架子。

怎么说呢，没要求就不写

涉及数据库的怎么写？

不写，能来得及写业务代码就不错了

写，强制要求增量代码覆盖率 70%

@rlds 确实，写不写单测要看给不给写单测的机会

写，最近让 AI 写，挺快的

我都是先写测试，然后把测试的一部分代码复制写到一个方法，然后再写个测试验证一下。

写;存量, 增量都要>=90%

不写，有问题用户会反馈的[= =]

@aw2350 很多种方法
1. stub 用自己的类代替
2. 如果写了 dao 层, 自己另外实现一个 dao 去返回
3. 没有 dao 层, 直接连接数据库操作对象, 可以 mock 数据库操作对象
4. 最后的办法可以启动一个数据库实例

楼上都是神仙吗, 90% 的单测, 话说你们的业务都很简单?

写，时间紧的话就先延后，找时间补上。

@seth19960929 同感，业务复杂的项目能做到百分之六七十的覆盖率就费了老劲了，太多的 stub 、mock 用例不仅写起来复杂而且测试的意义也大打折扣，很多时候就是为了完成 KPI

会的，后续业务有改动或者优化，或者有啥 bug 还是单测方便的

尽量覆盖主流程的简单情况，涉及外部系统就很难搞了

无副作用的核心方法必须单测。涉及数据库等外部操作的就等集成测试再说。单测覆盖率低的原因大概率是抽象不好，外部操作在核心业务逻辑中侵入太深

我们硬性要求 单测覆盖率增量 80% 低于则无法 MR
写业务代码和写单测时间 3:7

会给业务写集成测试，但单测基本没机会写。不写单测的原因有两个，一是我们的业务很少拆分成可测试的独立单元；二是我不想 mock 任何跟 io 相关的东西

😂测试代码要好写 业务代码得先写好

其实我一直不明白单元测试有什么意义，因为我一定会让单元测试能跑通的，感觉就是有点倒果为因

不忙就写，忙就算了； 天天加班的时候，就不写了

当代码可测的时候。

主动，但覆盖率不太高，核心的地方写一下。作用还是很大的

@xueyuehua 有意义呀 能让你放心大胆改底层代码
特别是一些工具方法

当然要区分系统集接口测试和单测

必须写。
因为写单测对代码结构是有要求的，比如代码耦合必须使用接口，哪怕想偷一点懒在写代码的时候没有考虑过测试，后续的代码就都完全没法写单测了。
然后改代码的成本就会越来越高，直到整个代码完全不可修改。

@seth19960929 如果 mock 了数据库，建议是把这部分直接和业务逻辑剥离， 还更靠谱些。

@SoviaPhilo 抽离了就得去实现一套数据库操作层, 不管是 mock 还是 faker 一个数据库连接, 都是为了写所谓的数据库操作层 (不应该为了写测试而写测试)

@Ryan7sz 对, 有时候有些依赖直接写死了, 根本测不出内部返回的错误, 然后自己去封装一层再写测试, 这就有点为了测试而测试了
@xueyuehua 写了之后, 下次别人接手你的代码可以提前发现错误 >_

必须写

必须写 感觉是为了测试而测试 甚至上了所谓的变异测试 非常离谱
业务与测试 3:7 甚至 2:8
可能是因为主要是存量业务的原因吧

@seth19960929 #41 testcontainers

@Seayon 我不用这个，侵入式的这个。我用 go-mysql-server ，或者直接 gitlab ci 启动一个容器就好

@Seayon 我们组也是用这个，加上 gomonkey 给其他函数打桩，感觉够了

游戏相关的项目，大部分功能没办法写单元测试，因为它们依赖的条件太多，无法构成一个“单元”，只有功能单一偏向于数值计算的函数会写单元测试。
所以游戏行业很依赖测试团队，以及内测公测之类的大规模用户测试。

@maninfog 同感；没单元测试的核心代码是没信心的。

@seth19960929 #62 怎么理解 Testcontainers 侵入的？我以为这个已经尽量不侵入了

@Seayon #66 直接通过 ci 启动对应的依赖, 测试还是直接连接服务呀