golang-单元测试结合web后台项目实战（重构和mock）

最新推荐文章于 2023-10-31 15:23:31 发布

xiaoliizi

最新推荐文章于 2023-10-31 15:23:31 发布

阅读量1.6k

点赞数 1

分类专栏： golang 文章标签： golang 单元测试

本文链接：https://blog.csdn.net/xiaoliizi/article/details/111770872

版权

golang 专栏收录该内容

14 篇文章 1 订阅

订阅专栏

文章目录

一、背景介绍
二、测试框架选用
- 2.1 sqlmock（不够通用）
- 2.2 业务代码抽象 + testify + gomonkey 结合
三、实际实现
四、总结

一、背景介绍

经过上一节对单元测试框架的基本学习，我们已经掌握了单元测试的基本写法
但是对一个web 后台项目来说，往往需要依赖一些基础服务（数据库、缓存等），实际生产环境当然是要连接这些基础服务的，但是测试环境不一定能连通这些服务（测试环境最好是要能），因此编写mock 也是一个比较必要的过程。

如何让测试代码写得更好，结合业务代码更优雅，也让后人能够更方便地开发，是一个需要探索的过程。这篇文章将会通过我的一个测试项目的重构过程，介绍如何更好地从单测框架的选用，到项目的重构，再到最后单测代码（数据库mock）的编写，一个完整的流程

我自己的项目git 地址
 跟重构相关的提交

二、测试框架选用

2.1 sqlmock（不够通用）

数据库操作这块，有一个开源的mock 框架，sqlmock
在这里插入图片描述
但是这限于使用原生sql.DB 类，使用起来才方便，如果业务用到了其他 orm 框架（如：gorm）就不方便了

2.2 业务代码抽象 + testify + gomonkey 结合

最终选用了这种方式
测试框架为什么选择 testify + gomonkey 前一篇博客有介绍：使用更加方便，和业务代码耦合性也不强

业务代码需要抽象成对象的原因：原来的业务方法都是直接放到业务的公共方法中，层级感不强
重构的基本思路就是将数据库连接池管理、业务操作管理都抽象成对象

最终当所有资源层、service 层和 controller 层都封装成对象的时候，就不会再有这三层中的对象，在var 中直接初始化业务对象的情况了（最多初始化锁），这样写起mock 来才会更方便

三、实际实现

3.1 框架设计

在这里插入图片描述

3.2 业务代码重构具体实现

首先项目架构还是比较经典的 controller - service - 数据层架构，下面从这三层分别介绍重构方式

3.2.1 DB 层

原实现：所有的DB 操作方法，都放到mysql 这一个package 的公共方法中，也没有封装成对象的方法
service 和 controller 层其实都是这么实现的，因此三层的重构思路都是类似的：将package 的公共方法抽象到对象的方法中

// https://gitee.com/atamagaii/mygoproject/blob/307b555ed5d6969169f27e05dc08aa3bf20ffdd2/src/database/mysql/schooldata.go
package mysql
......
func GetStudentSimpleInfoById(dbSchool *gorm.DB, studentId string) *model.Student {
	currentStudent := new(model.Student)
	err := dbSchool.Where("id = ?", studentId).Select("id, name, sex").Offset(0).Limit(10).
		First(&currentStudent).Error
	if nil != err {
		log.Printf("[GetStudentSimpleInfoById] 查询DB错误，请检查: %s", err.Error())
	}
	return currentStudent
}

现实现：按上图的设计，首先会有一个DB 资源管理对象，另外具体业务的数据，也会有一个独立的管理类，如下：

package resource
......
var (
	// 数据库连接管理 单例
	dbControllerInstance DBControllerInterface
	// 数据库连接管理单例 获取锁
	dbControllerInstanceLock = sync.Once{}
)

// 获取数据库连接管理单例
func NewDBController() DBControllerInterface {
	dbControllerInstanceLock.Do(func() {
		dbControllerInstance = new(GormController)
		dbControllerInstance.InitResource()
	})
	return dbControllerInstance
}

// 数据库连接管理 接口定义
type DBControllerInterface interface {
	InitResource() error
	GetStudentController() studentsql.StudentDataInterface
}

// Gorm 连接资源管理 实际实现类
type GormController struct {
	// 学生数据处理controller
	studentController studentsql.StudentDataInterface
}

// gorm 控制类: 获取学校数据业务操作对象
func (controller *GormController) GetStudentController() studentsql.StudentDataInterface {
	return controller.studentController
}

// Gorm 连接初始化
// 包含两部分初始化：gorm 连接初始化、数据操作初始化（将初始化成功的gorm 连接池绑定过去）
func (controller *GormController) InitResource() error {
	dbSchool := config.GetDBConnection(mysql.DB_NAME_LOCAL)
	controller.studentController = new(studentsql.StudentDataController)
	controller.studentController.SetDBResource(dbSchool)
	return nil
}

// Gorm 连接资源管理，mock 类
type GormMockController struct {
	studentController studentsql.StudentDataInterface
}

// gorm mock 类 资源初始化
func (controller *GormMockController) InitResource() error {
	controller.studentController = new(studentsql.StudentDataMockController)
	controller.studentController.SetDBResource(nil)
	return nil
}
......

DB 资源管理类：分别定义了 DBControllerInterface、GormController 和 GormMockController ，参考前面的架构图示例，分别表示 DB 控制器接口定义、实际实现类和 mock 类。

package studentsql
......
// 学生数据处理 接口
type StudentDataInterface interface {
	SetDBResource(*gorm.DB)
	GetStudentSimpleInfoById(string) *model.Student
	GetStudentSimpleInfoByName(string) *model.Student
	UpdateStudentGrade(*model.Student) int64
	GetGradeSummaryByGradeId(string) []*model.GradeSummary
	GetAllStudentName() []string
}

// 学生信息处理 实际实现类
type StudentDataController struct {
	// gorm 连接池
	dbSchool *gorm.DB
}

// 设置gorm 连接池，初始化的时候要执行
func (controller *StudentDataController) SetDBResource(db *gorm.DB) {
	controller.dbSchool = db
}

// 通过学生id获取学生的基本信息
func (controller *StudentDataController) GetStudentSimpleInfoById(studentId string) *model.Student {
	currentStudent := new(model.Student)
	err := controller.dbSchool.Where("id = ?", studentId).Select("id, name, sex").Offset(0).Limit(10).
		First(&currentStudent).Error
	if nil != err {
		log.Printf("[GetStudentSimpleInfoById] 查询DB错误，请检查: %s", err.Error())
	}
	return currentStudent
}
......

// 学生信息处理 mock 类
type StudentDataMockController struct{}

// mock: 设置gorm 连接池
func (controller *StudentDataMockController) SetDBResource(db *gorm.DB) {
	log.Printf("[mock] mock db init, will not actually init!")
}
......

学生数据处理类：同样定义了三个类：StudentDataInterface、StudentDataController和 StudentDataMockController，关系和 DB 资源控制类是类似的。
InitResource 方法的实现原理：因为 DBController 是要给上层（service层）用的，因此 DBController 和 StudentDataController 本身的对应关系要自己确认清楚，比如 GormMockController 初始化其StudentDataController 对象的时候，就要用 StudentDataMockController ，也就是都要用mock 类。

tips：单例模式锁这里用到了 sync.Once 来实现，参考博客

3.2.2 service

service 层主要是对SchoolService 对象的抽象，原实现：

package schoolservice

......

func GetStudentById(id string) *model.Student {
	log.Printf("[GetStudentById] 获取学生信息，学生id: %s", id)
	return mysql.GetStudentSimpleInfoById(mysql.DBSchool, id)
}
......

现实现：

package schoolservice

......

// 学校业务处理类
type SchoolService struct {
	dbController dbresource.DBControllerInterface
}

var (
	// 学校业务处理单例对象
	schoolServiceInstance *SchoolService
	// 获取学校 业务处理单例对象锁
	schoolServiceInstanceLock = sync.Once{}
)

// 获取学校业务处理对象
func NewSchoolService() *SchoolService {
	schoolServiceInstanceLock.Do(func() {
		schoolServiceInstance = new(SchoolService)
		schoolServiceInstance.dbController = dbresource.NewDBController()
	})
	return schoolServiceInstance
}

// 根据学生id 获取学生信息
func (service *SchoolService) GetStudentById(id string) *model.Student {
	log.Printf("[GetStudentById] 获取学生信息，学生id: %s", id)
	return service.dbController.GetStudentController().GetStudentSimpleInfoById(id)
}
......

3.2.3 controller

重构思路同上，现实现：

package schoolcontroller

......

// 学校业务逻辑控制层
type SchoolController struct {
	schoolService *schoolservice.SchoolService
}

var (
	// 学校controller 单例
	schoolControllerInstance *SchoolController
	// 学校controller 单例锁
	schoolControllerInstanceLock = sync.Once{}
)

// 获取学校controller 对象 单例
func NewSchoolController() *SchoolController {
	schoolControllerInstanceLock.Do(func() {
		schoolControllerInstance = new(SchoolController)
		schoolControllerInstance.initSchoolController()
	})
	return schoolControllerInstance
}

// 初始化学校controller
func (controller *SchoolController) initSchoolController() {
	controller.schoolService = schoolservice.NewSchoolService()
}

// 通过学生id 获取学生信息（只查DB）
func (controller *SchoolController) GetStudentById(context *gin.Context) {
	studentId := context.Query("id")
	student := controller.schoolService.GetStudentById(studentId)
	context.JSON(200, student)
}
......

3.3 测试代码实现

通过上面重构的过程，我们了解到 DB 层是有专门的mock 方法的，因此只要将实际DB controller 的初始化方法，mock 成 mock类的初始化方法就可以了：

func TestGetStudentById(t *testing.T) {
	currentMock := gomonkey.ApplyFunc(dbresource.NewDBController, dbresource.NewDBMockController)
	defer currentMock.Reset()
	schoolService := schoolservice.NewSchoolService()
	student := schoolService.GetStudentById("1")
	assert.NotEqual(t, "", student.Name)
}

关键就是第一步：将 dbresource.NewDBController mock 成 dbresource.NewDBMockController
后面照常执行业务逻辑就行，由于DB controller 已经被mock 了，最终DB 层逻辑也会走mock 类的逻辑。至于你是想让mock 类查测试DB，还是只是返回一个虚拟的查询结果，就看实际测试的需求了
建议修改操作还是要连接测试DB ，真正跑数据库方法执行（修改操作影响比较大，最好有一个实际验证的过程），查询操作返回一个虚拟结果就行了。

四、总结

1、从可测试性来看：只有把对象封装好，对象的初始化都改成主动调用初始化方法，而不是使用 init 方法，或者直接在 var 中初始化，后续所有的方法、对象才能更方便地写mock。
如上面介绍，如果后续业务要新加一个接口，只需要在业务实际实现类（StudentDataController）和 mock 类（StudentDataMockController）中定义新接口就可以了。
同样，如果开发想要给一个查询接口，新加一种查询场景，也是只要修改实际的业务方法（StudentDataController.GetStudentSimpleInfoById），和在mock 类的方法（StudentDataMockController.GetStudentSimpleInfoById）中，新加对应场景的逻辑就可以了，结构非常清楚。

2、从资源初始化来看：初始化操作都改成主动之后，只有第一次“被用到”的资源才会被初始化，服务刚启动，还没有流量进来的时候，是不会做任何初始化动作的，避免在服务依赖外部资源的时候，启动需要花费非常长的时间。
不过，这当然也要求了服务在资源初始化的时候，需要做更多的异常检测和提醒机制。

3、从服务运营能力来看：每一层都抽象成对象之后，基本就不存在什么执行业务逻辑还要用到全局变量的情况了，所有的资源都是通过一个“管理员对象” 来操作的。
这样封装好之后，后续还可以做更多事情：比如DB层可以做可用连接数的自监控，service 层可以做常用方法统计，controller 层可以做针对用户级别的流量控制，等等。

通过这次对自己测试项目的重构，我更加意识到了：任何需求都是要经过详细的设计，要思考很多可扩展性、可测试性，之后再实现，才能够真正对“需求”本身负责，写出来的代码和功能才能够真正“可维护”。
只是为了实现需求的目标而写代码，最终写出来的代码对自己、对后人都将会是灾难性的后果。

xiaoliizi

关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
1
评论
golang-单元测试结合web后台项目实战（重构和mock）

文章目录一、背景介绍二、测试框架选用三、实际实现一、背景介绍经过上一节对单元测试框架的基本学习，我们已经掌握了单元测试的基本写法但是对一个web 后台项目来说，往往需要依赖一些基础服务（数据库、缓存等），实际生产环境当然是要连接这些基础服务的，但是测试环境不一定能连通这些服务（测试环境最好是要能），因此编写mock 也是一个比较必要的过程。如何让测试代码写得更好，结合业务代码更优雅，也让后人能够更方便地开发，是一个需要探索的过程。这篇文章将会通过我的一个测试项目的重构过程，介绍如何更好地从单测
复制链接

扫一扫

专栏目录