项目demo地址go-test本文主要针对golang语言的单元测试工具博客内容也会涉及一些单元相关的内容**什么是单元测试**单元测试是软件测试体系中最基础、最核心的测试类型它聚焦于对软件系统中最小的 “可测试单元” 进行独立验证确保该单元的功能符合预期设计。**简单描述下前因后果**工作需要对项目代码系统化执行单元测试要求覆盖率达到95%以上因为不同人的开发风格和代码习惯外加项目框架和架构的一些要求。单元测试这个东西一般情况都会让人很痛苦至于因为啥我相信看到我这篇博客的各位都是有不同程度的感同身受的我这里介绍三种单测工具基础的单元测试书写和使用就不过多赘述了。一、单元测试的核心方式注意这块作为扩展如需直接了解工具可忽略这部分单元测试的实现方式可从核心分类维度展开结合具体落地实践和技术选型不同方式适用于不同场景和项目规模。1、按测试编写时机划分核心流程维度从开发流程角度区分的两种核心方式决定了单元测试与业务代码的协作关系。1.后写单元测试传统方式最常用核心定义先编写业务功能代码待功能实现完成后再针对性补写对应的单元测试用例验证已实现的代码逻辑是否符合预期。适用场景大部分传统开发场景、快速迭代的小型需求、开发者对 TDD 模式不熟悉的项目。优势符合开发者 “先实现功能再验证” 的直觉上手成本低无需提前设计详细的测试用例。劣势可能遗漏部分边界场景的测试且容易因业务代码耦合度高导致测试难以编写后期补测时修改代码解耦的成本更高。2.测试驱动开发TDDTest-Driven Development进阶方式核心定义遵循 “先写测试再写业务代码最后重构” 的循环流程测试用例先定义好被测单元的预期行为输入、输出、异常场景再编写满足测试用例的业务代码最终优化代码结构。核心流程红 - 绿 - 重构循环红Red编写一个失败的测试用例此时业务代码未实现测试必然失败绿Green编写最少的业务代码仅满足让该测试用例通过不追求代码优雅只保证功能达标重构Refactor在测试用例保驾护航的前提下优化业务代码的结构、可读性、性能等确保重构后测试用例仍能通过。适用场景对代码质量要求高的核心模块、复杂业务逻辑、需要长期维护的大型项目。优势强制开发者提前梳理需求和接口设计减少后期需求偏差测试用例覆盖率更高天然覆盖正常、边界、异常场景重构无风险测试用例作为 “安全网”确保重构不破坏原有功能代码耦合度更低因为先写测试会倒逼开发者设计可测试的代码如依赖接口而非具体实现。2、按依赖处理方式划分技术实现维度这是单元测试落地的核心技术维度决定了如何隔离外部依赖保证测试的独立性。1. 基于 Mock/Stub 的单元测试主流方式核心定义当被测单元依赖外部资源数据库、RPC 服务、HTTP 接口、文件系统等时通过 ** 模拟Mock或桩Stub** 实现替代真实依赖预设返回值或行为从而脱离外部环境限制专注测试业务逻辑。Mock vs Stub 区别通俗理解类型核心特征适用场景Stub仅预设固定返回值无行为验证只需依赖返回值完成业务逻辑测试Mock不仅预设返回值还可验证依赖方法是否被调用、调用次数、参数是否正确需要验证业务逻辑对依赖的调用行为实现方式手动编写 Mock/Stub简单场景如之前 Go 示例中手动实现UserDB接口的MockUserDB预设返回值工具自动生成 Mock复杂场景Go 生态的gomockmockgen、Java 生态的Mockito、Python 生态的unittest.mock可根据接口自动生成 Mock 代码支持更灵活的行为验证。优势测试独立、快速、可复现不受外部资源状态影响能覆盖各种异常场景如依赖服务报错、超时。Go 语言工具示例gomock1先安装工具go get github.com/golang/mock/gomockgo install github.com/golang/mock/mockgenlatest2自动生成 Mock 代码无需手动编写支持验证调用行为。2. 真实依赖单元测试小众场景核心定义不使用模拟实现直接使用真实的外部依赖如真实数据库、真实 HTTP 服务进行单元测试验证被测单元与真实依赖的协作是否正常。适用场景依赖逻辑简单、真实依赖易于搭建和控制如本地轻量数据库 SQLite、对依赖协作正确性要求极高的场景。优势测试结果更贴近生产环境能发现与真实依赖协作的潜在问题如 SQL 语法错误、接口参数不匹配。劣势测试执行速度慢依赖外部资源启动和初始化测试结果不稳定受外部资源状态影响如数据库数据被修改导致测试失败测试环境搭建复杂需要统一管理依赖配置如数据库连接信息、服务地址。示例测试数据库查询函数时直接连接本地测试 MySQL 数据库预先插入测试数据执行查询后验证结果最后清理测试数据。3、个人理解上面的描述是大模型系统化生成的内容下面是博主自行整理的至于为什么会有这样一段赘述是和下面的工具有些关联单元测试两种开发方式1.方式一先开发业务代码后写单元测试代码常用interface单元测试核心优势完全解耦外部依赖实现 “纯净” 测试灵活覆盖全量业务场景无测试死角测试执行效率极高支持高频执行为代码重构提供 “安全网”降低重构风险倒逼良好的代码设计提升代码质量可验证依赖方法的调用行为进阶优势缺点增加前期开发成本引入额外代码量存在 “过度抽象” 的风险无法验证真实依赖的协作正确性Mock 与真实实现可能存在 “行为不一致”对简单场景 “杀鸡用牛刀”性价比不高总结如果代码开发的时候考虑到需要进行单元测试功能开发可以直接在业务功能开发时进行单元测试的预先埋点处理做好接口的开发不过一般情况下大家的开发习惯都不会考虑单元测试这种情况这时候在想要回去处理单元测试interface这种方式就会极为麻烦和笨重单测时间成本成指数级增长。使用单元测试工具内置核心工具testing包基础基石工具包具体使用方法和功能下面介绍接口测试工具httptest数据库测试工具go-sqlmock打桩测试工具gomonkey优点在业务逻辑代码开发完成后几乎可以不调整原始逻辑代码进行单元测试代码开发2.方式二先开发单元测试代码后写逻辑代码很少见不介绍二、单元测试命令go test -v运行当前包下单元测试-v 打印详细日志go test -run “^$”运行单元测试函数go test -v 文件名_test.go 业务文件.go运行单文件单元测试函数go test ./…运行整个目录的单元测试文件包括子目录下的单元测试文件go test -cover覆盖率统计go test ./… -cover整个目录覆盖率统计包括子目录go test -coverprofilecover.out当前目录执行测试 生成覆盖率统计的【原始数据文件】cover.out (核心基础必须先执行)go tool cover -funccover.out当前目录以【纯文本、按函数】展示覆盖率详情终端直接看快速统计go tool cover -htmlcover.out -o cover.html当前目录生成【可视化HTML报告文件】cover.html最实用精准看哪行代码未覆盖go test -coverprofilecover.out ./…整个目录操作包括子目录go test -run “^$” -gcflagsall-l-gcflagsall-l 禁用所有包的内联优化gomonkey官方推荐的打桩必须使用不过这个和覆盖率-cover参数有冲突推荐覆盖率计算和单测执行分开使用go test -run “^$” -cover -gcflagsall-l -covermodeatomic-covermodeatomic 可以强制禁用内内联优化和执行覆盖率不过有时不会生效三、单元测试工具主要介绍三个工具httptest、go-sqlmock、gomonkey1、httptestCSDN链接-单元测试-httptest博客园链接-单元测试-httptest2、go-sqlmockCSDN链接-单元测试-go-sqlmock博客园链接-单元测试-go-sqlmock3、gomonkeyCSDN链接-单元测试-gomonkey博客园链接-单元测试-gomonkey