啥？你们想不增加研发人力或者成本的情况下，想通过单测降低测试成本？ 想屁吃呢

我们的单元测试就是掩耳盗铃，只能说是在提交测试的时候代码能通过，后面就没人跑了

@peteretep 也不是这样，一些复杂系统，单元测试比人靠谱多了，例如报税的系统，单元测试测的又快又准，你让一个人测，上百个功能点，不同的场景，让人去做，非常不靠谱。但要达到这样的效果，一个好的架构师是很必要的，首先要能高效的执行单元测试，整个代码的设计就必须满足可测的设计。模块的分离是不是够清晰，外部依赖的设计是不是容易构建，这些都影响单元测试的可实现。

首先搞清楚一件最基本的事情：单测全覆盖全通过，也不代表用户测试能通过

领导规定一个测试覆盖率，不愿做的，分不到钱啊，就这么简单 测试和文档 AI 能帮助的太多了，基本就是改改的事

@bloomy8 #46 同意，在原来排期下加时间就完事了，这帮人老想着时间不变活你得多干，自己没当过大头兵吗？

你要实现单元测试，先把系统改造成单元测试友好的系统，一个手电筒的系统，灯泡可以单独测试，控制开关可以单独验证信号输出，电池可以单独测试电量输出的稳定性。但很多系统就是一座屎山，为了测一个功能，至少要拉起七八个模块，还不知道怎么能让每个模块正确初始化，每个场景都很难模拟，写单元测试的人就会直接崩溃掉。

前几年吃到 COVID-19 红利的公司, 2020 年中的时候开始运动式的搞单元测试轰轰烈烈的, 也是上面那个要求. 几年后我因为某件事情问一个开发经理, 你们的单元测试呢, 不是有单元测试么? 那位直接说, 那是假的, 不作数的. 不要只看一开始创建 UT 的成本投入, 后期维护的成本可大着呢。

@snowlyg http 相对容易，gorm 单测才是巨坑。我用 gorm + postgresql ，能改 table_prefix ，不能改 index 的（因为写在注解里面）。毕竟众所周之，pg 的 index 名称是库级别唯一，而不是 table 级别唯一，就很搞。

开猿节流，降本增笑嘛 https://i.imgur.com/agAJ0Rd.png