KingHL

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

我在团队内推行过单测的落地，我们团队现在单测已经常态化运行，可以和楼主聊一聊：

首先我对“使用了 go 全局变量的框架，没有使用依赖注入，没有使用接口和抽象，导致非常难写单测”这个不是很理解，现在业界成熟单测框架对各类对象的 mock 功能已经非常成熟了，你这个难写是指难以组织单测目录结构、还是难以卸除可用的单测例子。

对于数据库，推荐使用 Sqlite 创建一个本地数据库，在单测环境初始化的时候创建表并插入数据，拒绝引入任何依赖，方便后续单测代码维护。

单测用例也有不同的写法，比如最细粒度的，针对函数/方法级别设计单测用例，这种的好处是单测用例好编写，坏处是单测用例基本没有组织逻辑，全是零散用例；也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高。

单测写完只是第一步，对单测用例的维护是一个非常重的工作，必须前期设计好单测运行流程、单测组织结构、单测用例编写规范，建议从某个独立工程开始试点，真正把单测的编写和维护流程跑通，拿到收益。

单测会反推开发者进行更合理的代码结构拆分，提高代码质量，建议从增量代码开始卡点，增量代码写单测负担小，易于推行，并且效果直观。

单测代码行覆盖率只是一个可用观测指标，都是 70%的行覆盖率，单测真正覆盖了多少业务场景，执行了多少分支流程差别很大，重要的还是用例设计，所以建议 CR 对用例进行 review 。

猜测你这是履历上体现的能力没跟上工作年限，互联网太残酷，稍微慢点跟不上，就会被淘汰，最终突围的十不足一。

@pandachow 这个牛啊，不持有任何固定资产，是在国内吗

@popvlovs 你真是挺搞笑的，真把自己当救世主活菩萨了

这个云厂商的价格对比有没有算上人力成本？谁出钱？

工作挺有意思，有没有更全面的介绍？