Mock依賴

有的時候，由于業(yè)務(wù)邏輯的復(fù)雜性，功能代碼并不會就這么直接，往往還會摻雜很多其他組件，這就給我們的測試工作帶來很大的麻煩，我這里列舉幾個常見的依賴：

• 組件依賴
• 函數(shù)依賴

組件依賴和函數(shù)依賴是兩種比較常見的依賴，但是，這兩種依賴也是可以擴展開來說的，既可能來自于我們自己編寫的組件/函數(shù)，也可能是引入其他人寫的。但是，無妨，對于這些情況，我們都會做一些分析

組件依賴處理

傳一個 Stub 組件進入，從而達到控制依賴組件行為的效果

舉一個例子先，例如我們比較常見的 Service 層和 DAO 層的操作，Service 處理完邏輯之后，交給 DAO 層進行持久化，或者需要調(diào)用 DAO 層從持久化中獲取一些必要的數(shù)據(jù)；在測試的時候，我們很多時候不希望真的持久化或者從持久化中獲取數(shù)據(jù)，那么就會對 DAO 層進行一些 Mock

import "fmt"type Data struct {Field string }type Dao interface {ReadAll() []DataSaveData(d *Data) }type MongoDao struct {}func (d MongoDao) ReadAll() []Data {return []Data{} }func (d MongoDao) SaveData(data *Data) {//... }type Service struct {Dao *Dao }func (s *Service) Login (username string) bool {users := (*s.Dao).ReadAll()for _, user := range users {if username == user.Field {return true}}return false }func Newservice(d Dao) *Service {srv := Service{Dao: &d}return &srv }func main() {d := MongoDao{}srv := Newservice(d)fmt.Println(srv.Login("abc")) }

這里我們想要測試Service的正確性，但是又不想要真的持久化 DAO，所以，這個時候我們會自己創(chuàng)建一個 Stub，然后提供給 Service，同時，我們還能操作 DAO 的行為，達到運行得效果

//用StubDao代替Mongodb type StubDao struct {}func (d StubDao) ReadAll() []Data {return []Data{Data{"abc"}} }func (d StubDao) SaveData(data *Data) { }func TestLogin(t *testing.T) {d := StubDao{}srv := NewService(d)rst := srv.Login("abc")if !rst {t.Error("login error")} }

這里對測試代碼稍微改了一下，可以發(fā)現(xiàn)，我們可以通過修改一個變量來控制 Stub 的輸出，從而達到測試不同功能的效果，這就解決了組件依賴的問題

函數(shù)依賴

函數(shù)依賴相比于組件依賴會更麻煩一點，因為我們在前面可以看到，組件依賴的話我們可以傳遞 Stub 進行，這樣我們可以隨意得控制 Stub 的行為，但是函數(shù)不行呀，這里我們又不能傳函數(shù)進去，因為函數(shù)是被 import 進去的啊。問題就在這了，因為函數(shù)是被 import 進去的，所以可以理解為函數(shù)是全局的了，既然這樣，那么我們?yōu)槭裁床恍薷囊幌潞瘮?shù)呢？什么意思？我們先來看著正常的業(yè)務(wù)例子

var Login = func(username, password string) bool {if username == password {return false}return true }func Reply(username, password, msg string) bool {if Login(username, password) {fmt.Println(msg)return true}return false }func stu() {Reply("a", "b", "aa")Reply("a", "b", "bb") }

要先登錄，然后登錄完之后我們才能回復(fù)消息，這里我們的登錄邏輯是簡單的，但是，在實際業(yè)務(wù)中可能這里的登錄邏輯就設(shè)計到 DB 訪問等等，我們希望不走真實的邏輯，而是自己來控制Login的行為

先分析一下我們的 UT 目的，我們的目的是測試Reply函數(shù)，我們期望是Login成功，那么Reply也應(yīng)該是成功的；如果Login失敗，那么Reply也應(yīng)該是失敗的。這個測試結(jié)論不應(yīng)該被Login所影響，及時以后Login邏輯修改了，我們也應(yīng)該是這個邏輯，不會受到影響，那么我們可以這么編寫 UT

func TestSuccReply(t *testing.T) {origLogin := Logindefer func() {Login = origLogin}()Login = func(username, password string) bool {return true}if !Reply("a", "a", "aaa") {t.Errorf("reply false for login success")} }func TestLogin(t *testing.T) {origLogin := Logindefer func() {Login = origLogin}()Login = func(username, password string) bool {return false}if Reply("a", "a", "aa") {t.Errorf("reply true for login fail")} }

這里可以發(fā)現(xiàn)，我們是修改了Login這個函數(shù)的代碼，從而控制Login函數(shù)的返回值，這樣我們就可以測試我們寫的代碼的邏輯是否正確了

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的golang中的Mock依赖的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。