单元测试 on 菜鸟程序员

Golang单元测试-wire依赖注入

Mon, 01 Jan 0001 00:00:00 +0000

Golang依赖注入框架wire全攻略

在前一阵介绍单元测试的系列文章中，曾经简单介绍过wire依赖注入框架。但当时的wire还处于alpha阶段，不过最近wire已经发布了首个beta版，API发生了一些变化，同时也承诺除非万不得已，将不会破坏API的兼容性。在前文中，介绍了一些wire的基本概况，本篇就不再重复，感兴趣的小伙伴们可以回看一下：搞定Go单元测试（四）—— 依赖注入框架(wire)。本篇将具体介绍wire的使用方法和一些最佳实践。

本篇中的代码的完整示例可以在这里找到：wire-examples

Installing

go get github.com/google/wire/cmd/wire

Quick Start

我们先通过一个简单的例子，让小伙伴们对wire有一个直观的认识。下面的例子展示了一个简易wire依赖注入示例：

$ ls
main.go wire.go

main.go

package main

import "fmt"

type Message struct {
 msg string
}
type Greeter struct {
 Message Message
}
type Event struct {
 Greeter Greeter
}
// NewMessage Message的构造函数
func NewMessage(msg string) Message {
 return Message{
 msg:msg,
 }
}
// NewGreeter Greeter构造函数
func NewGreeter(m Message) Greeter {
 return Greeter{Message: m}
}
// NewEvent Event构造函数
func NewEvent(g Greeter) Event {
 return Event{Greeter: g}
}
func (e Event) Start() {
 msg := e.Greeter.Greet()
 fmt.Println(msg)
}
func (g Greeter) Greet() Message {
 return g.Message
}

// 使用wire前
func main() {
 message := NewMessage("hello world")
 greeter := NewGreeter(message)
 event := NewEvent(greeter)

 event.Start()
}
/*
// 使用wire后
func main() {
 event := InitializeEvent("hello_world")

 event.Start()
}*/

wire.go

Golang单元测试-简单示例

Mon, 01 Jan 0001 00:00:00 +0000

one.go

package unittest

func AddOne(t int32) int32 {
 return t + 1
}

func MinusOne(t int32) int32 {
 return t - 1
}

func MultiAddOne(t int32) int32 {
 t = MinusOne(t)
 t = AddOne(t)
 t = AddOne(t)
 return t
}

one_test.go

package unittest

import (
 "testing"

 . "github.com/agiledragon/gomonkey"
 . "github.com/smartystreets/goconvey/convey"
)

func TestMultiAddOne(t *testing.T) {
 Convey("TestApplyFunc", t, func() {
 Convey("input and output param", func() {
 patches := ApplyFunc(AddOne, func(t1 int32) int32 {
 return 5
 }) //对函数AddOne打桩
 defer patches.Reset()
 patches.ApplyFunc(MinusOne, func(t1 int32) int32 {
 return -2
 }) //对函数MinusOne打桩
 result := MultiAddOne(2) //看好了我调用的是MultiAddOne函数，而MultiAddOne函数内部调用了AddOne和MinusOne。
 So(result, ShouldEqual, 3)
 })
 })
}

Golang单元测试01

Mon, 01 Jan 0001 00:00:00 +0000

搞定Go单元测试（一）——基础原理

单元测试是代码质量的保证。本系列文章将一步步由浅入深展示如何在Go中做单元测试。

Go对单元测试的支持相当友好，标准包中就支持单元测试，在开始本系阅读之前，需要对标准测试包的基本用法有所了解。

现在，我们从单元测试的基本思想和原理入手，一起来看看如何基于Go提供的标准测试包来进行单元测试。

单元测试的难点

1.掌握单元测试粒度

单元测试粒度是让人十分头疼的问题，特别是对于初尝单元测试的程序员。测试粒度做的太细，会耗费大量的开发以及维护时间，每改一个方法，都要改动其对应的测试方法。当发生代码重构的时候那简直就是噩梦（因为你所有的单元测试又都要写一遍了…）。如单元测试粒度太粗，一个测试方法测试了n多方法，那么单元测试将显的非常臃肿，脱离了单元测试的本意，容易把单元测试写成集成测试。

2. 破除外部依赖（mock,stub 技术）

单元测试一般不允许有任何外部依赖（文件依赖，网络依赖，数据库依赖等），我们不会在测试代码中去连接数据库，调用api等。这些外部依赖在执行测试的时候需要被模拟(mock/stub)。在测试的时候，我们使用模拟的对象来模拟真实依赖下的各种行为。如何运用mock/stub来模拟系统真实行为算是单元测试道路上的一只拦路虎。别着急，本文会通过示例来展示如何在Go中使用mock/stub来完成单元测试。

有的时候模拟是有效的方便的。但我们要提防过度的mock/stub，因为其会导致单元测试主要在测模拟对象而不是实际的系统。

Costs and Benefits

在受益于单元测试的好处的同时，也必然增加了代码量以及维护成本（单元测试代码也是要维护的）。下面这张成本/价值象限图很清晰的阐述了在不同性质的系统中单元测试成本和价值之间的关系。

1.依赖很少的简单的代码(左下)

对于外部依赖少，代码又简单的代码。自然其成本和价值都是比较低的。举Go官方库里errors包为例，整个包就两个方法 New()和 Error()，没有任何外部依赖，代码也很简单，所以其单元测试起来也是相当方便。

2. 依赖较多但是很简单的代码（右下）

依赖一多，mock和stub就必然增多，单元测试的成本也就随之增加。但代码又如此简单（比如上述errors包的例子），这个时候写单元测试的成本已经大于其价值，还不如不写单元测试。

3. 依赖很少的复杂代码 (左上)

像这一类代码，是最有价值写单元测试的。比如一些独立的复杂算法（银行利息计算，保险费率计算，TCP协议解析等），像这一类代码外部依赖很少，但却很容易出错，如果没有单元测试，几乎不能保证代码质量。

4.依赖很多又很复杂（右上）

这种代码显然是单元测试的噩梦。写单元测试吧，代价高昂；不写单元测试吧，风险太高。像这种代码我们尽量在设计上将其分为两部分：1.处理复杂的逻辑部分 2.处理依赖部分然后1部分进行单元测试

原文参考：blog.stevensanderson.com/2009/11/04/…

迈出单元测试第一步

1. 识别依赖，抽象成接口

识别系统中的外部依赖，普遍来说，我们遇到最常见的依赖无非下面几种：

网络依赖——函数执行依赖于网络请求，比如第三方http-api，rpc服务，消息队列等等
数据库依赖
I/O依赖（文件）

当然，还有可能是依赖还未开发完成的功能模块。但是处理方法都是大同小异的——抽象成接口，通过mock和stub进行模拟测试。

2. 明确需要测什么

当我们开始敲产品代码的时候，我们必然已经过初步的设计，已经了解系统中的外部依赖以及业务复杂的部分，这些部分是要优先考虑写单元测试的。在写每一个方法/结构体的时候同时思考这个方法/结构体需不需要测试？如何测试？对于什么样的方法/结构体需要测试，什么样的可以不做，除了可以从上面的成本/价值象限图中获得答案外，还可以参考以下关于单元测试粒度要做多细问题的回答：

Golang单元测试02

Mon, 01 Jan 0001 00:00:00 +0000

搞定Go单元测试（二）—— mock框架(gomock)

通过阅读上一篇文章，相信你对怎么做单元测试已经有了初步的概念，可以着手对现有的项目进行改造并开展测试了。学会了走路，我们尝试跑起来，本篇主要介绍gomock测试框架，让我们的单元测试更加有效率。

表格驱动测试方法(Table Driven Tests)

当针对某方法进行单元测试的时候，通常不止写一个测试用例，我们需要测试该方法在多种入参条件下是否都能正常工作，特别是要针对边界值进行测试。通常这个时候表格驱动测试就派上用场了——当你发现你在写测试方法的时候用上了复制粘贴，这就说明你需要考虑使用表格驱动测试来构建你的测试方法了。我们依旧来举个例子：

func TestTime(t *testing.T) {
 testCases := []struct { // 设计我们的测试用例
 gmt string
 loc string
 want string
 }{
 {"12:31", "Europe/Zuri", "13:31"}, // incorrect location name
 {"12:31", "America/New_York", "7:31"}, // should be 07:31
 {"08:08", "Australia/Sydney", "18:08"},
 }
 for _, tc := range testCases { // 循环执行测试用例
 loc, err := time.LoadLocation(tc.loc)
 if err != nil {
 t.Fatalf("could not load location %q", tc.loc)
 }
 gmt, _ := time.Parse("15:04", tc.gmt)
 if got := gmt.In(loc).Format("15:04"); got != tc.want {
 t.Errorf("In(%s, %s) = %s; want %s", tc.gmt, tc.loc, got, tc.want)
 }
 }
}

表格驱动测试方法让我们的测试方法更加清晰和简练，减少了复制粘贴，并大大提高的测试代码的可读性。

还记得上文说单元测试也是需要维护的吗？单元测试也是代码的一部分，也应当被认真对待。记得要用表格驱动测试的方法来组织你的测试用例，同时别忘了像正式代码那样，写上相应的注释。更多参考： github.com/golang/go/w… blog.golang.org/subtests

使用测试框架——gomock

What is gomock?

gomock是Google开源的golang测试框架。或者引用官方的话来说：“GoMock is a mocking framework for the Go programming language”。

Golang单元测试03

Mon, 01 Jan 0001 00:00:00 +0000

搞定Go单元测试（三）—— 断言（testify）

在上一篇，介绍了表格驱动测试方法和gomock测试框架，大大提升了测试效率与质量。本篇将介绍在测试中引入断言（assertion），进一步提升测试效率与质量。

为什么需要断言库

我们先来看看Go标准包中为什么没有断言，官方在FAQ里面回答了这个问题。

golang.org/doc/faq#ass…

总体概括一下大意就是：“Go不提供断言，我们知道这会带来一定的不便，其主要目的是为了防止你们这些程序员在错误处理上偷懒。我们知道这是一个争论点，但是我们觉得这样很coooool~~。”所以，我们引入断言库的原因也很明显了：偷懒，引入断言能为我们提供便利——提高测试效率，增强代码可读性。

testify

在断言库的选择上，我们似乎没有过多的选择，从start数和活跃度来看，基本上是testify一枝独秀。

github.com/stretchr/te…

没有对比就没有伤害，先来看看使用testify之前的测试方法：

func TestSomeFun(t *testing.T){
...
 if v != want {
 t.Fatalf("v值错误，期望值：%s，实际值：%s", want, v)
 }
 if err != nil {
 t.Fatalf("非预期的错误：%s", err)
 }
 if objectA != objectB {
 if objectA.field1 != objectB.field1 {
 // t.Fatalf() field1值错误...bla bla bla
 }
 if objectA.field2 != objectB.field2 {
 // t.Fatalf() field2值错误...bla bla bla
 }
 // 遍历object所有值... bla bla bla
 }
...
}

上述代码充斥着大量if...else..判断，大段错误信息拼装（真·体力活…），运气不好碰到结构体判断要得将其遍历一遍——不直观，低效，实在是不fashion。现在，我们使用 testify来改造一下上面的测试示例：

func TestSomeFun(t *testing.T){
 a := assert.New(t)
...
 a.Equal(v, want)
 a.Nil(err,"如果你还是想输出自己拼装的错误信息，可以传第三个参数")
 a.Equal(objectA, objectB)
...
}

三行搞定，测试含义一目了然——直观，高效，简短，fashion。

总结一下

testify使用简单，提升显著，可谓是用一次就会爱上的懒人神器。在结合表格驱动测试，gomock和testify后，我们已经能写出一手优雅漂亮的单元测试代码了。不过，光测试代码优雅还不够，我们还需要帮main.go也打扮打扮。在下一篇，也是本系列最后一篇文章中，我们将介绍wire依赖注入框架，帮main.go减肥瘦身。

Golang单元测试04

Mon, 01 Jan 0001 00:00:00 +0000

搞定Go单元测试（四）—— 依赖注入框架(wire)

在第一篇文章中提到过，为了让代码可测，需要用依赖注入的方式来构建我们的对象，而通常我们会在main.go做依赖注入，这就导致main.go会越来越臃肿。为了让单元测试得以顺利进行，main.go牺牲了它本应该纤细苗条的身材。太胖的main.go可不是什么好的信号，本篇将介绍依赖注入框架（wire），致力于帮助main.go恢复身材。

臃肿的main

在main.go中做依赖注入，意味着在初始化代码中我们要管理：

依赖的初始化顺序
依赖之间的关系

对于小型项目而言，依赖的数量比较少，初始化代码不会很多，不需要引入依赖注入框架。但对于依赖较多的中大型项目，初始化代码又臭又长，可读性和维护性变的很差，随意感受一下：

func main() {
 config := NewConfig()
 // db依赖配置
 db, err := ConnectDatabase(config)
 if err != nil {
 panic(err)
 }
 // PersonRepository 依赖db
 personRepository := NewPersonRepository(db)
 // PersonService 依赖配置 和 PersonRepository
 personService := NewPersonService(config, personRepository)
 // NewServer 依赖配置和PersonService
 server := NewServer(config, personService)
 server.Run()
}

实践表明，修改有大量依赖关系的初始化代码是一项乏味且耗时的工作。这个时候，我们就需要依赖注入框架来帮忙，简化初始化代码。

上述代码来自：blog.drewolson.org/dependency-…

使用依赖注入框架——wire

What is wire?

wire是google开源的依赖注入框架。或者引用官方的话来说：“Wire is a code generation tool that automates connecting components using dependency injection”。

github.com/google/wire

Why wire?

除了wire，Go的依赖注入框架还有Uber的dig和Facebook的inject，它们都是使用反射机制来实现运行时依赖注入(runtime dependency injection)，而wire则是采用代码生成的方式来达到编译时依赖注入(compile-time dependency injection)。使用反射带来的性能损失倒是其次，更重要的是反射使得代码难以追踪和调试（反射会令Ctrl+左键失效…）。而wire生成的代码是符合程序员常规使用习惯的代码，十分容易理解和调试。关于wire的优点，在官方博文上有更详细的的介绍： blog.golang.org/wire