Go單元測試對GORM進(jìn)行Mock測試

更新時間：2022年06月21日 16:10:03 作者：kevinyan

這篇文章主要為大家介紹了Go單元測試對GORM進(jìn)行Mock測試用例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

前言

在 Go 單元測試這個系列的第二部分數(shù)據(jù)庫的Mock測試中我們介紹了用 go-sqlmock 給數(shù)據(jù)庫的 CRUD 操作做Mock 測試的方法，不過里面只是講解了一下怎么對原生的database/sql執(zhí)行的 SQL 進(jìn)行 Mock 測試。

真實的開發(fā)場景下我們的項目一般都會使用 ORM ，而不是原生的database/sql來完成數(shù)據(jù)庫操作。在很多使用ORM工具的場景下，也可以使用go-sqlmock庫 Mock數(shù)據(jù)庫操作進(jìn)行測試，今天這篇內(nèi)容我就以 GORM 為例，講解怎么給項目中的 ORM 數(shù)據(jù)庫操作做單元測試。

項目準(zhǔn)備

為了場景足夠真實，我用 2020 年我更新的「Go Web 編程入門」項目中的例子給大家演示怎么為使用了 GORM 的 DAO 層邏輯做 Mock 測試。

這里使用的GORM版本為 1.x，有可能在2.x版本下不兼容

在這個例子中我們有一個與 users 表

type User struct {
	Id        int64     `gorm:"column:id;primary_key"`
	UserName  string    `gorm:"column:username"`
	Secret    string    `gorm:"column:secret;type:varchar(1000)"`
	CreatedAt time.Time `gorm:"column:created_at"`
	UpdatedAt time.Time `gorm:"column:updated_at"`
}
func (m *User) TableName() string {
	return "users"
}

以及幾個使用 User 的 DAO 函數(shù)：

var _DB *gorm.DB
func DB() *gorm.DB {
	return _DB
}
func init() {
  //這里邏輯省略，就是初始化 GORM 的DB對象，
  // 設(shè)置連接數(shù)據(jù)庫的配置
	_DB = initDB() 
}
func CreateUser(user *table.User) (err error) {
	err = DB().Create(user).Error
	return
}
func GetUserByNameAndPassword(name, password string) (user *table.User, err error) {
	user = new(table.User)
	err = DB().Where("username = ? AND secret = ?", name, password).
		First(&user).Error
	return
}
func UpdateUserNameById(userName string, userId int64) (err error) {
	user := new(table.User)
	updated := map[string]interface{}{
		"username": userName,
	}
	err = DB().Model(user).Where("id = ?", userId).Updates(updated).Error
	return
}

接下來我們就用 go-sqlmock 工具給這幾個 DAO 函數(shù)做一下 Mock 測試。

初始化測試工作

首先我們需要做一下測試的初始化工作，主要是設(shè)置Mock的DB連接，因為要給三個方法做Mock測試，最簡單的辦法是在三個方法里每次都初始化一遍 Mock 的 DB 連接，不過這么做實在是顯得有點蠢，這里給大家再介紹一個小技巧。

Go 的測試支持在包內(nèi)優(yōu)先執(zhí)行一個 TestMain(m *testing.M) 函數(shù)，可以在這里為 package 下所有測試做一些初始化的工作。

下面是我們?yōu)楸敬螠y試做的初始化工作。

var (
	mock sqlmock.Sqlmock
	err  error
	db   *sql.DB
)
// TestMain是在當(dāng)前package下，最先運行的一個函數(shù)，常用于初始化
func TestMain(m *testing.M) {
  //把匹配器設(shè)置成相等匹配器，不設(shè)置默認(rèn)使用正則匹配
	db, mock, err = sqlmock.New(sqlmock.QueryMatcherOption(sqlmock.QueryMatcherEqual))
	if err != nil {
		panic(err)
	}
	_DB, err = gorm.Open("mysql", db)
	// m.Run 是調(diào)用包下面各個Test函數(shù)的入口
	os.Exit(m.Run())
}

在這個初始化函數(shù)里我們創(chuàng)建一個 sqlmock 的數(shù)據(jù)庫連接 db 和 mock對象，mock對象管理 db 預(yù)期要執(zhí)行的SQL。
讓sqlmock 使用 QueryMatcherEqual 匹配器，該匹配器把mock.ExpectQuery 和 mock.ExpectExec 的參數(shù)作為預(yù)期要執(zhí)行的SQL語句跟實際要執(zhí)行的SQL進(jìn)行相等比較。
m.Run 是調(diào)用包下面各個Test函數(shù)的入口。

準(zhǔn)備工作做好了，下面正式對 DAO 操作進(jìn)行Mock測試。

對Create進(jìn)行Mock測試

首先對 GORM 的Create 方法進(jìn)行Mock測試。

func TestCreateUserMock(t *testing.T) {
	user := &table.User{
		UserName:  "Kevin",
		Secret:    "123456",
		CreatedAt: time.Now(),
		UpdatedAt: time.Now(),
	}
	mock.ExpectBegin()
	mock.ExpectExec("INSERT INTO `users` (`username`,`secret`,`created_at`,`updated_at`) VALUES (?,?,?,?)").
		WithArgs(user.UserName, user.Secret, user.CreatedAt, user.UpdatedAt).
		WillReturnResult(sqlmock.NewResult(1, 1))
	mock.ExpectCommit()
	err := CreateUser(user)
	assert.Nil(t, err)
}

因為 sqlmock 使用的是 QueryMatcherEqual 匹配器，所以，預(yù)期會執(zhí)行的 SQL 語句必須精確匹配要執(zhí)行的SQL（包括符號和空格）。

這個SQL怎么獲取呢？其實我們先隨便寫一個SQL，執(zhí)行一次測試，在報錯信息里就會告知CreateUser 操作在寫表時 GORM 真正要執(zhí)行的 SQL 啦，也可以通過GORM提供的Debug()方法獲取到。

比如運行一下下面這個設(shè)置了Debug()的創(chuàng)建用戶操作，GORM就會打印出執(zhí)行的語句。

func CreateUser(user *table.User) (err error) {
	// 打印出要執(zhí)行的SQL語句 ，記得改回去
  err = DB().Debug().Create(user).Error
	// err = DB().Create(user).Error
	return
}

我們執(zhí)行下這個測試

 go test -v -run TestCreateUserMock
--------
=== RUN   TestCreateUserMock
--- PASS: TestCreateUserMock (0.00s)
PASS
ok      golang-unit-test-demo/sqlmock_gorm_demo 0.301s

可以看到，測試函數(shù)執(zhí)行成功，我們還可以故意把SQL改成，做一下反向測試，這個就留給你們自己聯(lián)系啦，結(jié)合上表格測試分別做一下正向和反向單元測試。

Get 操作的Mock測試

GORM 的查詢操作的Mock測試跟Create類似。

func TestGetUserByNameAndPasswordMock(t *testing.T) {
	user := &User{
		Id:        1,
		UserName:  "Kevin",
		Secret:    "123456",
		CreatedAt: time.Now(),
		UpdatedAt: time.Now(),
	}
	mock.ExpectQuery("SELECT * FROM `users`  WHERE (username = ? AND secret = ?) "+
		"ORDER BY `users`.`id` ASC LIMIT 1").
		WithArgs(user.UserName, user.Secret).
		WillReturnRows(
			// 這里要跟結(jié)果集包含的列匹配，因為查詢是 SELECT * 所以表的字段都要列出來
			sqlmock.NewRows([]string{"id", "username", "secret", "created_at", "updated_at"}).
				AddRow(1, user.UserName, user.Secret, user.CreatedAt, user.UpdatedAt))
	res, err := GetUserByNameAndPassword(user.UserName, user.Secret)
	assert.Nil(t, err)
	assert.Equal(t, user, res)
}

這里就不在文章里運行演示啦，有興趣的自己把代碼拿下來試一下。

Update 操作的Mock測試

GORM的Update操作我沒有測試成功，我這里發(fā)出來原因

func TestUpdateUserNameByIdMock(t *testing.T) {
	newName := "Kev"
	var userId int64 = 1
	mock.ExpectBegin()
	mock.ExpectExec("UPDATE `users` SET `updated_at` = ?, `username` = ?  WHERE (id = ?)").
		WithArgs(time.Now(), newName, userId).
		WillReturnResult(sqlmock.NewResult(1, 1))
	mock.ExpectCommit()
	err := UpdateUserNameById(newName, userId)
	assert.Nil(t, err)
}

運行測試后，會有下面的報錯信息：

ExecQuery 'UPDATE `users` SET `updated_at` = ?, `username` = ? WHERE (id = ?)', arguments do not match: argument 0 expected [time.Time - 2022-05-08 18:13:08.23323 +0800 CST m=+0.003082084] does not match actual [time.Time - 2022-05-08 18:13:08.234134 +0800 CST m=+0.003986334]

GORM 在UPDATE 的時候會自動更新updated_at 字段為當(dāng)前時間，與這里withArgs傳遞的 time.Now() 參數(shù)不一致（毫秒級的差距也不行）。

這種情況可以選擇在 Mock 要執(zhí)行的更新 SQL 時給 update_at字段的值設(shè)置成sqlmock.AnyArg()，就能測試通過了，上面的 UPDATE 測試改成下面這樣：

  mock.ExpectBegin()
  mock.ExpectExec("UPDATE `users` SET `updated_at` = ?, `username` = ?  WHERE (id = ?)").
    WithArgs(sqlmock.AnyArg(), newName, userId).
		WillReturnResult(sqlmock.NewResult(1, 1))
	mock.ExpectCommit()

這個方法是sqlmock提供的用來斷言匹配任意字段值的一個特殊的類型。在其注釋里也有說明，尤其適合time.Time類型字段的斷言。

// AnyArg will return an Argument which can
// match any kind of arguments.
//
// Useful for time.Time or similar kinds of arguments.
func AnyArg() Argument {
	return anyArgument{}
}

當(dāng)然使用sqlmock.AnyArg()在測試代碼的可讀性上，以及嚴(yán)謹(jǐn)性上都會差點意思，因為如果真實執(zhí)行的 SQL 中如果updated_at字段設(shè)置的值不是time.Time類型的，使用sqlmock.AnyArg()做斷言匹配是無法測出來的。

所以我們也可以選擇實現(xiàn)自己定義一個 AnyTime 類型，讓它實現(xiàn)sqlmock.Argument接口，比如下面的示例：

// 定義一個AnyTime 類型，實現(xiàn) sqlmock.Argument接口
// 參考自：https://qiita.com/isao_e_dev/items/c9da34c6d1f99a112207
type AnyTime struct{}
func (a AnyTime) Match(v driver.Value) bool {
	// Match 方法中：判斷字段值只要是time.Time 類型，就能驗證通過
	_, ok := v.(time.Time)
	return ok
}

在 AnyTime 類型實現(xiàn)接口定義的Match方法的邏輯是：判斷字段值只要是time.Time 類型，就能驗證通過。這種方式比使用 sqlmock.AnyArg() 限制性更強(qiáng)一些，代碼可讀性也會更好。

	mock.ExpectBegin()
	mock.ExpectExec("UPDATE `users` SET `updated_at` = ?, `username` = ?  WHERE (id = ?)").
		WithArgs(AnyTime{}, newName, userId).
		WillReturnResult(sqlmock.NewResult(1, 1))
	mock.ExpectCommit()