单元测试(go)

本文主要针对golang语言的单元测试工具，博客内容也会涉及一些单元相关的内容

什么是单元测试：单元测试是软件测试体系中最基础、最核心的测试类型，它聚焦于对软件系统中最小的 “可测试单元” 进行独立验证，确保该单元的功能符合预期设计。

简单描述下前因后果：工作需要对项目代码系统化执行单元测试，要求覆盖率达到95%以上，因为不同人的开发风格和代码习惯，外加项目框架和架构的一些要求。单元测试，这个东西一般情况都会让人很痛苦，至于因为啥，我相信看到我这篇博客的各位，都是有不同程度的感同身受的，我这里介绍三种单测工具，基础的单元测试书写和使用就不过多赘述了。

一、单元测试的核心方式

注意：这块作为扩展，如需直接了解工具可忽略这部分

单元测试的实现方式可从核心分类维度展开，结合具体落地实践和技术选型，不同方式适用于不同场景和项目规模。

1、按测试编写时机划分

（核心流程维度）

从开发流程角度区分的两种核心方式，决定了单元测试与业务代码的协作关系。

1.后写单元测试

（传统方式，最常用）

核心定义：先编写业务功能代码，待功能实现完成后，再针对性补写对应的单元测试用例，验证已实现的代码逻辑是否符合预期。
适用场景：大部分传统开发场景、快速迭代的小型需求、开发者对 TDD 模式不熟悉的项目。
优势：符合开发者 “先实现功能再验证” 的直觉，上手成本低，无需提前设计详细的测试用例。
劣势：可能遗漏部分边界场景的测试，且容易因业务代码耦合度高，导致测试难以编写（后期补测时，修改代码解耦的成本更高）。

2.测试驱动开发

（TDD，Test-Driven Development，进阶方式）

核心定义：遵循 “先写测试，再写业务代码，最后重构” 的循环流程，测试用例先定义好被测单元的预期行为（输入、输出、异常场景），再编写满足测试用例的业务代码，最终优化代码结构。
核心流程（红 - 绿 - 重构循环）：
1. 红（Red）：编写一个失败的测试用例（此时业务代码未实现，测试必然失败）；
2. 绿（Green）：编写最少的业务代码，仅满足让该测试用例通过（不追求代码优雅，只保证功能达标）；
3. 重构（Refactor）：在测试用例保驾护航的前提下，优化业务代码的结构、可读性、性能等，确保重构后测试用例仍能通过。
适用场景：对代码质量要求高的核心模块、复杂业务逻辑、需要长期维护的大型项目。
优势：
- 强制开发者提前梳理需求和接口设计，减少后期需求偏差；
- 测试用例覆盖率更高，天然覆盖正常、边界、异常场景；
- 重构无风险，测试用例作为 “安全网”，确保重构不破坏原有功能；
- 代码耦合度更低，因为先写测试会倒逼开发者设计可测试的代码（如依赖接口而非具体实现）。

2、按依赖处理方式划分

（技术实现维度）

这是单元测试落地的核心技术维度，决定了如何隔离外部依赖，保证测试的独立性。

1. 基于 Mock/Stub 的单元测试

（主流方式）

核心定义：当被测单元依赖外部资源（数据库、RPC 服务、HTTP 接口、文件系统等）时，通过 ** 模拟（Mock）或桩（Stub）** 实现替代真实依赖，预设返回值或行为，从而脱离外部环境限制，专注测试业务逻辑。

Mock vs Stub 区别（通俗理解）：

类型	核心特征	适用场景
Stub	仅预设固定返回值，无行为验证	只需依赖返回值完成业务逻辑测试
Mock	不仅预设返回值，还可验证依赖方法是否被调用、调用次数、参数是否正确	需要验证业务逻辑对依赖的调用行为

实现方式：
1. 手动编写 Mock/Stub（简单场景）：如之前 Go 示例中，手动实现UserDB接口的MockUserDB，预设返回值；
2. 工具自动生成 Mock（复杂场景）：Go 生态的gomock+mockgen、Java 生态的Mockito、Python 生态的unittest.mock，可根据接口自动生成 Mock 代码，支持更灵活的行为验证。
优势：测试独立、快速、可复现，不受外部资源状态影响，能覆盖各种异常场景（如依赖服务报错、超时）。
Go 语言工具示例（gomock）：

（1）先安装工具：
```
go get github.com/golang/mock/gomock
```
```
go install github.com/golang/mock/mockgen@latest
```
（2）自动生成 Mock 代码，无需手动编写，支持验证调用行为。

2. 真实依赖单元测试

（小众场景）

核心定义：不使用模拟实现，直接使用真实的外部依赖（如真实数据库、真实 HTTP 服务）进行单元测试，验证被测单元与真实依赖的协作是否正常。
适用场景：依赖逻辑简单、真实依赖易于搭建和控制（如本地轻量数据库 SQLite）、对依赖协作正确性要求极高的场景。
优势：测试结果更贴近生产环境，能发现与真实依赖协作的潜在问题（如 SQL 语法错误、接口参数不匹配）。
劣势：
- 测试执行速度慢，依赖外部资源启动和初始化；
- 测试结果不稳定，受外部资源状态影响（如数据库数据被修改导致测试失败）；
- 测试环境搭建复杂，需要统一管理依赖配置（如数据库连接信息、服务地址）。
示例：测试数据库查询函数时，直接连接本地测试 MySQL 数据库，预先插入测试数据，执行查询后验证结果，最后清理测试数据。

3、个人理解

上面的描述是大模型系统化生成的内容，下面是博主自行整理的，至于为什么会有这样一段赘述，是和下面的工具有些关联

单元测试两种开发方式：

1.方式一

先开发业务代码，后写单元测试代码（常用）

interface单元测试
1. 核心优势：
  - 完全解耦外部依赖，实现 “纯净” 测试
  - 灵活覆盖全量业务场景，无测试死角
  - 测试执行效率极高，支持高频执行
  - 为代码重构提供 “安全网”，降低重构风险
  - 倒逼良好的代码设计，提升代码质量
  - 可验证依赖方法的调用行为（进阶优势）
2. 缺点：
  - 增加前期开发成本，引入额外代码量
  - 存在 “过度抽象” 的风险
  - 无法验证真实依赖的协作正确性
  - Mock 与真实实现可能存在 “行为不一致”
  - 对简单场景 “杀鸡用牛刀”，性价比不高
3. 总结：
  
  如果代码开发的时候考虑到需要进行单元测试功能开发，可以直接在业务功能开发时进行单元测试的预先埋点处理，做好接口的开发，不过一般情况下大家的开发习惯都不会考虑单元测试这种情况，这时候在想要回去处理单元测试，interface这种方式就会极为麻烦和笨重，单测时间成本成指数级增长。
使用单元测试工具
1. 内置核心工具：testing包（基础基石）
2. 工具包（具体使用方法和功能下面介绍）
  - 接口测试工具：httptest
  - 数据库测试工具：go-sqlmock
  - 打桩测试工具：gomonkey
3. 优点：
  
  在业务逻辑代码开发完成后几乎可以不调整原始逻辑代码进行单元测试代码开发

2.方式二

先开发单元测试代码，后写逻辑代码（很少见，不介绍）

二、单元测试命令

go test -v

运行当前包下单元测试；-v 打印详细日志

go test -run "^$"

运行单元测试函数

go test -v 文件名_test.go 业务文件.go

运行单文件单元测试函数

go test ./...

运行整个目录的单元测试文件，包括子目录下的单元测试文件

go test -cover

覆盖率统计

go test ./... -cover

go test -coverprofile=cover.out

当前目录，执行测试 + 生成覆盖率统计的【原始数据文件】cover.out (核心基础，必须先执行)

go tool cover -func=cover.out

当前目录，以【纯文本、按函数】展示覆盖率详情（终端直接看，快速统计）

go tool cover -html=cover.out -o cover.html

当前目录，生成【可视化HTML报告文件】cover.html（最实用，精准看哪行代码未覆盖）

go test -coverprofile=cover.out ./...

go test -run "^$" -gcflags=all=-l

-gcflags=all=-l 禁用所有包的内联优化，gomonkey官方推荐的打桩必须使用，不过这个和覆盖率-cover参数有冲突，推荐覆盖率计算和单测执行分开使用

go test -run "^$" -cover -gcflags=all=-l -covermode=atomic

-covermode=atomic 可以强制禁用内内联优化和执行覆盖率，不过有时不会生效

单元测试(go)

一、单元测试的核心方式

1、按测试编写时机划分

1.后写单元测试

2.测试驱动开发

2、按依赖处理方式划分

1. 基于 Mock/Stub 的单元测试

2. 真实依赖单元测试

3、个人理解

单元测试两种开发方式：

1.方式一

2.方式二

二、单元测试命令

三、单元测试工具

1、httptest

2、go-sqlmock

3、gomonkey

相关阅读

本类排行

相关标签

本类推荐

栏目热点

猜你喜欢