Go的单元测试技巧

单元测试（Unit Test）

Go语言原生支持测试工具go test，省去了各种各样测试框架的学习成本。说来也惭愧，写代码这么些年，也从来没有给自己的代码写过单元测试，代码质量的确堪忧。遂花时间学习整理了一下单元测试的基本方法，以及在Go中的实践技巧。

单元测试的难点

以下是我在尝试进行单元测试的过程中遇到的一些难点，在下文中会介绍相应的一些应对方案。

1.掌握单元测试粒度

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

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

单元测试中是不允许有任何外部依赖的，也就是说这些外部依赖都需要被模拟(mock)。外部依赖越多，mock越复杂。如何用模拟的依赖来测试真实依赖的行为？mock写的太简单，达不到测试的目的。mock太复杂， 不仅成本增加，而且又如何确保mock的正确性呢？

有的时候模拟是有效的方便的。但是其他一些时候，过多的模拟对象，Stub对象，假对象，导致单元测试主要在测模拟对象而不是实际的系统。

Costs and Benefits

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

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

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

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

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

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

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

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

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

原文参考：http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

迈出单元测试第一步