什么是单元测试

<figure class="image"></figure>有没有遇到过类似的情况,当你打算开始写出高质量的代码，为了写出高质量的代码，公司的大牛告诉你，写好单元测试是高质量代码的基石。然后你每次写完功能代码，总是给每个方法写大量的单元测试，然后请教大牛，没想到大牛冷冷的说一句：你写的不是单元测试，它测到别的东西。

这时候你的脑袋里会不会像浆糊一样，还有这样说法，单元测试还能测到别的东西？

那么我们来思考一个问题，什么是(真正的)单元测试，为什么会测到别的东西？

为了避免写出不是单元测试的单元测试，我们需要知道什么是单元测试,这里采用维基百科的说法：

Unit tests are typically automated tests written and run by software developers to ensure that a section of an application(known as the “unit”) meets its design and behaves as intended.

单元测试基本上是有软件开发人员编写并执行的自动化测试，用以确认一段代码（单元）符合预期的设计和行为

再来看看专家的意见，The Art of Unit Testing的作者Roy Osherave是这么说的

A unit test is an automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It’s trust-worthy, readable, and maintainable. It’s consistent in its results as long as production code hasn’t changed.

单元测试是一段能自动执行的代码，这段代码会去调用一个工作单元并确认该工作单元最终的单一结果符合一些假设。单元测试几乎总是按照单元测试框架编写踹的。它能够被轻易的编写并且快速执行。它值得信任，可读并且容易维护。只要单元测试的代码没有变化，单元测试的运行结果必定总是保持一致。

维基百科的定义通俗易懂，重点是符合预期的设计和行为，它点出了被测试单元不仅仅是一段代码，而且还蕴含着开发者期望的一个情境或行为；重点是情境或行为而不是被测试代码本身。而大师的定义能看出一下几点：

1、可以使用測試框架(Testing Framework)快速编写。

2、能夠被快速的執行

3、易於閱讀與維護

4、值得信任，並且只要code沒變的狀況下都可以持續獲得一致的測試結果

我们需要谈论的重点是第四点，是什么情况产生了不一致的结果，一种情况就是被测试代码进行了修改；还有一种情况就是被测试代码没有变化，但是被测试代码的依赖太多，依赖发生变化导致不一致的结果。

我们单元测试的业务逻辑，也会因为别人修改了代码而遭受破坏。因此单元测试的重点是只测试自己想要的业务情境，而不应该测试依赖代码的业务逻辑。因此我们必须想办法避开别人代码的业务逻辑。这应该怎么做呢？简单来说就是伪造依赖代码的返回结果。我們在开发时必定是期待相依的逻辑能夠返回我們需要的結果，換句話說开发人員對於依赖逻辑总是有不同的意圖，为此我们总结出一下四点：

1、单元测试的测试目标

2、单元测试的特性

3、为了要单纯测试自己的业务逻辑，需要避开依赖代码的逻辑

4、开发人员期待依赖逻辑能帮忙完成任务

根据上述期待和意图的不同，需要分成几种不同的处理方式，它们就分别对应mock/stub/spy/fake。

至于上面的几种处理方式该怎么使用，我们再以后的文章中继续分享。希望大家深刻理解单元测试的定义，这样我们在后面学习的时候能够更加深入理解和实践。