全局变量也是可以的，虽然麻烦些 先说关于依赖的处理，如果数据库是 MySQL 的话比较方便，可以使用 github.com/dolthub/go-mysql-server 在本地内存起一个，然后改配置文件，连接这个内存实例，这个库可以当做是 Go 实现的 MySQL 可以配套运行一些脚本建表与造一些数据，这样测起来方便 但是这个库运行某些 SQL 会有问题（绝大部分时候正常），这时候就上 https://github.com/testcontainers/testcontainers-go 用容器起数据库，包括 PostgreSQL 也只能这样 Redis 可以用 https://github.com/alicebob/miniredis 其他依赖直接 gomonkey 打桩 具体来说，可以先实现一个通用的造环境函数准备好数据库之类，每个测试开始调用一下（或者 test Main ，这个方法很多） 之后造 HTTP 请求调 handler ，之后用 testify 检查返回与数据库更改是否符合要求（比方说更新后再查一下是否已更新）

@GallifreyCAR 业务功能写单元测试没什么大的用处，我一直觉得除非你研发的是底层框架类库才有必要写单元测试

加钱+不写绩效不及格 or 延长一倍开发时间+不写绩效不及格

一般就核心模块要求单测覆盖率呗，整个项目单测成本太高了

另外不写测试或者 Statements 测试没有 95%的，在我这里只值 8000RMB/月

@Erroad #15 哈哈 外企还真是，覆盖率必须 80%以上，除 shi 山项目外的新项目，覆盖率不够是没法 merge PR 的

之前我们也推单元测试代码覆盖率,然后一个功能 3 天,写单元测试再要 3 天工时,后面就基本不咋让写单元测试了,尤其是有很多 rpc 调用场景,需要 mock 一堆服务,然后改了一点业务代码,可能需要几十倍的工作量改测试代码

@momo2789 为了覆盖率写测试 本末倒置。

@NX2023 数据库我是用这个库实现的 github.com/DATA-DOG/go-sqlmock ，外部调用服务的情况，我目前还没想到同步好的方式，但是 gomonkey 是个很好思考方向。

@GallifreyCAR #4 业务交叉情况，得让测试先准备完备的测试数据，才能自动/手动跑覆盖，达到测试目的。按方案 1 改改，外部服务数据都是可以 mock 的呀。 然后单测和方案 1 的全流程测试是两回事，单测也考虑依赖完备的测试数据，不然光写“单测”意义不大。 举个例子，假设原有项目是商城上下架商品，现在增加 1 个商品优惠券功能。那测试得先准备 1 个商品测试数据，再基于此做优惠券测试。