使用gomock对golang项目进行单元测试
熟悉golang的工程师应该都会利用golang自带的go test工具对自己的代码进行单元测试，go test除了能够自动的进行单元测试、输出格式化结果之外，还可以输出对应的覆盖率统计，借助覆盖率统计信息，我们可以看到单测中覆盖到和没有覆盖到的代码行，从而对单测进行一定的优化。
gomock其实也是一个官方的、用于优化单测的工具。
gomock用在什么地方
以下我们以一个例子说明什么情况下需要用到gomock这个工具
src/fetcher/fetcher.go
package fetcher
import (
"fmt"
"net/http"
)
type Fetcher interface {
Get(string) (*http.Response, error)
}
func (httpFetcher *HttpFetcher) Get(query string) (*http.Response, error) {
url := fmt.Sprintf("%s://%s:%d/%s", httpFetcher.Protocol, httpFetcher.Host, httpFetcher.Port, query)
return http.Get(url)
}
type HttpFetcher struct {
Host string
Port int
Protocol string
}
func ServiceCheck(query string, fetcher Fetcher) {
resp, err := fetcher.Get(query)
if err != nil {
// todo: do something record
fmt.Printf("%v", err)
}
if resp.StatusCode == 404 {
// todo: do something record
fmt.Println("status code is 404")
return
} else if resp.StatusCode == 400 {
// todo: do something record
fmt.Println("status code is 400")
return
} else if resp.StatusCode != 200 {
// todo: do something record
return
}
// todo: do something record for status code 200
return
}
在fetcher.go函数中，定义了Fetcher这个接口类型，HttpFetcher实现了这个接口类型。而ServiceCheck这个函数，可以当作一个服务监控函数，它监控一个对应的url，当这个url返回的结果不为200时，它可以做一些记录或者调用某一个回调函数去报警。现在，如果我们需要对ServiceCheck这个函数去做单测，我们如何才能让我们的单测能够覆盖到请求结果的状态吗不为200的这些分支呢？
甚至先不考虑这些非200分支，你能不能保证自己的单测能够不受环境影响、独立的运行？如果你在单测的时候提供一个指向测试环境服务的url，在你自己的测试环境下自然可以得到响应，但是离开这个测试环境，你的单测还能不能稳定的运行？
考虑到这些问题，我们需要一个mock工具，来解放在这个场景下对网络服务的依赖。如果我们可以mock出一个对象来替代HttpFetcher，并且重写对应的Get函数，就可以按照我们的想法，输出任意的*http.Response对象。
gomock介绍
gomock 是官方提供的 mock 框架，同时还提供了 mockgen 工具用来辅助生成测试代码。
使用如下命令即可安装：
go get -u github.com/golang/mock/gomock
go get -u github.com/golang/mock/mockgen
安装结束之后，$PATH下会新增一个mockgen的可执行文件，通过以下命令：
mockgen -source=./fetcher.go -destination=./mock/mock_fetcher.go -package=mock
可以对Fetcher这个接口生成对应的mock对象，我们不需要关注生成mock_fetcher.go文件的内容（看不懂，而且在使用中不需要关心）。随后对fetcher.go写单测：
src/fetcher/fetcher_test.go
package fetcher
import (
"net/http"
"testing"
fetcherMock"awesomeProject/fetcher/mock"
"github.com/golang/mock/gomock"
)
func TestHttpFetcher_Get_404(t *testing.T) {
query := "v4/resolve?dn=www.baidu.com&account_id=100195&ip=1.1.1.1&sign=9cc9723684867d" +
"5b5eb943431220790a&t=1866666666&cuid=xxxxxyyyyyzzzzz&type=dual_stack"
ctl := gomock.NewController(t)
defer ctl.Finish()
mock_resp := new(http.Response)
mock_resp.StatusCode = 404
mockFetcher := fetcherMock.NewMockFetcher(ctl)
mockFetcher.EXPECT().Get(query).Return(mock_resp, nil)
ServiceCheck(url, mockFetcher)
}
对应的目录树结构为：
├── fetcher.go
├── fetcher_test.go
└── mock
└── mock_fetcher.go
- gomock.NewController：返回
gomock.Controller，它代表 mock 生态系统中的顶级控件。定义了 mock 对象的范围、生命周期和期待值。另外它在多个 goroutine 中是安全的 - mock.NewMockFetcher：创建一个新的 mock 实例
- mockFetcher.EXPECT().Get(url).Return(mock_resp, nil)：这里有三个步骤，
EXPECT()返回一个允许调用者设置期望和返回值的对象。Get(query)是设置入参并调用 mock 实例中的方法。Return(mock_resp, nil)是设置先前调用的方法出参。简单来说，就是设置入参并调用，最后设置返回值
在fetcher/目录下执行go test，有以下输出：
status code is 404 PASS ok awesomeProject/fetcher 0.586s
可见mock成功了。这样的mock方式称为"打桩"，有明确的参数和对应的返回值。除此之外还有其它的打桩方式，有需要的可以自己去查询。
编写可测试的代码
如果仔细看以上的用例，可以发现gomock只能mock一个满足interface的类型，它对一个具体的类型是无能为力的。比如，如果我们使用这个函数定义：
func ServiceCheck(query string, fetcher HttpFetcher)
gomock是没办法mock出一个HttpFetcher实例的。而代码的可测试性和代码的可读性、高效性同等重要，因此，将依赖抽象为接口类型，不仅可以降低耦合度，还有利于写出方便测试的代码。
如果再仔细看这个函数，会发现它同样使用了依赖注入的方式降低耦合性。如果Fetcher的实例放在ServiceCheck函数内部去初始化，那么不仅是函数可测试性大打折扣，某个实现了Fetcher的类型也与ServiceCheck函数形成了紧耦合。
