這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。我們[當前項目的核心](https://heupr.io/)是一個 [MemSQL](https://www.memsql.com/) 資料庫，它是我們核心的資料管道；這是一個非常酷的技術，它的速度非常快，我們實在是太喜歡它了。但是，測試跟它相關的代碼卻有點困難，這個問題通過實驗或者當遇到錯誤（主要是遇到錯誤）時，很快就可以發現。由於 Go 標準包已通過全面的測試，我只需要確保調用和依賴他們的代碼在生產中也能夠正常運行就好。測試我們項目的資料庫代碼，我通過兩個步驟完成。通過 database/sql 包，我們有了 sql.DB 結構，它代表一系列mocks的串連，以及包含一系列與這些串連進行互動的方法。在我們的程式碼程式庫中，我們使用了其中的兩個（以及一個返回開啟的資料庫的函數）：```gofunc Open(driverName, dataSourceName string) (*DB, error)func (db *DB) Close() errorfunc (db *DB) Query(query string, args ...interface{}) (*Rows, error)```接著，我像下面這樣建立了一個名為 sqlDB 的介面：```gotype sqlDB interface {Open(driverName, dataSourceName string) (*sql.DB, error)Close() errorQuery(query string, args ...interface{}) (*sql.Rows, error)}```這是一個 “曲線救國” 的想法，我定義了一個由 sql.DB 結構方法實現的介面。有了這個介面，再加上單元測試可以直接使用測試對象，立馬就可以測試圍繞這些函數/方法的調用代碼。請注意，由於在傳回值中依賴了諸如 sql.Rows 之類的，導致需要一些額外的配置，但它確實讓需要測試的範圍更接近於實際的 database/sql 包（即，需要測試的東西更加少）。接著，我構建第二個步驟的測試。定義了一個 dataAccess 介面，其中包含返回，將供後面處理的，準備好的對象的特定方法。這些函數將調用上面的 sqlDB 介面定義的方法，（下面的）這些方法從我們的程式碼程式庫和單元測試中進一步封裝了 database/sql 包：```gotype dataAccess interface {readIntegrations(query string) (map[int64]*integration, error)readSettings(query string) (map[int64]*settings, error)readEvents(query string) (map[int64][]*preprocess.Container, error)}```再一次使用介面，可以讓我們在測試中替換更多的生產代碼，並讓我們在調用這些介面代碼時，可以關注（更多）不同的測試案例和情境。簡單地說：- sqlDB 介面可以讓我們立即測試與資料庫物件互動的相關代碼（而不需要真的啟動一個資料庫並注入各種表） - （例如）測試處理資料庫查詢之類的東西- dataAccess 介面允許我們對依賴它的值進行單元測試，例如上面返回的 map 結果 - 後面的想法也都是這樣對（依賴於）資料庫相關的代碼進行單元測試有不同的方法，而這就是我在 Go 項目中採用的方法 - 我非常樂意提供（我的）建議，或者方案，以及快樂地進行單元測試的方法！
via: https://dev.to/forstmeier/golang-database-mocks-1hm9
作者：John Forstmeier 譯者：gogeof 校對：rxcai
本文由 GCTT 原創編譯，Go語言中文網 榮譽推出
本文由 GCTT 原創翻譯，Go語言中文網 首發。也想加入譯者行列，為開源做一些自己的貢獻嗎？歡迎加入 GCTT！
翻譯工作和譯文發表僅用於學習和交流目的，翻譯工作遵照 CC-BY-NC-SA 協議規定，如果我們的工作有侵犯到您的權益，請及時聯絡我們。
歡迎遵照 CC-BY-NC-SA 協議規定 轉載，敬請在本文中標註並保留原文/譯文連結和作者/譯者等資訊。
文章僅代表作者的知識和看法，如有不同觀點，請樓下排隊吐槽
362 次點擊
