@baby0w0 我的理解是这个是职业操守，我从来没有要求过 TDD ，这个不现实。但是我不能接受写一个接口，一个单元测试都没有就发出去的，哪怕是 80%呢？

@wxw752 应该是变成 mvc 那样了.....

我在团队内推行过单测的落地，我们团队现在单测已经常态化运行，可以和楼主聊一聊： 首先我对“使用了 go 全局变量的框架，没有使用依赖注入，没有使用接口和抽象，导致非常难写单测”这个不是很理解，现在业界成熟单测框架对各类对象的 mock 功能已经非常成熟了，你这个难写是指难以组织单测目录结构、还是难以卸除可用的单测例子。 对于数据库，推荐使用 Sqlite 创建一个本地数据库，在单测环境初始化的时候创建表并插入数据，拒绝引入任何依赖，方便后续单测代码维护。 单测用例也有不同的写法，比如最细粒度的，针对函数/方法级别设计单测用例，这种的好处是单测用例好编写，坏处是单测用例基本没有组织逻辑，全是零散用例；也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高。 单测写完只是第一步，对单测用例的维护是一个非常重的工作，必须前期设计好单测运行流程、单测组织结构、单测用例编写规范，建议从某个独立工程开始试点，真正把单测的编写和维护流程跑通，拿到收益。 单测会反推开发者进行更合理的代码结构拆分，提高代码质量，建议从增量代码开始卡点，增量代码写单测负担小，易于推行，并且效果直观。 单测代码行覆盖率只是一个可用观测指标，都是 70%的行覆盖率，单测真正覆盖了多少业务场景，执行了多少分支流程差别很大，重要的还是用例设计，所以建议 CR 对用例进行 review 。

@NX2023 #81 我也不太接受，只有写这个 demo 的时候试验过，正式要搞太折磨了，不如直接改框架。

@KingHL 也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高 我们其实就是这种情况，业务要大量 mock 数据库返回，mock 缓存队列返回，mock 一些外部服务系统的返回， 要用上 各种库才能实现，类似 gomonkey, sqlmock 等等。所以我还是希望改造改造框架为依赖注入，拆分出抽象接口。但是我在同事间调研，大家不想写的心情居多，看了 f 回答，我觉得可能向上反馈，不推行也是一种方案。

@momo2789 你的理解没问题的。钱给够就可以了

@GallifreyCAR 参考我的回复，建一个 sqliite 本地数据库，注入到你的 orm 的 client 上，即可实现数据库替换，单测时会走到真正的数据库操作代码，不需要做数据库返回值的 mock ，数据库读写逻辑本身就是一个需要单测覆盖的部分，不建议直接 mock 掉数据库。

写单测开发时间不说翻倍起码也增加百分之 50 吧，旧代码不重构根本写不了

你们这个项目恐怕不是“非常难写单测”而是写不了单测吧

微服务时代，单测就是给自己找麻烦。走自动化的 API 测试吧。