写好单元测试

What

单元测试，是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++,Java这样的面向对象的语言中， 要进行测试的基本单元是类。但一般都是测试到方法.(包括重要的私有方法)

经常与单元测试联系起来的另外一些开发活动包括代码审查（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)(DEBUG 工具)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

其实我们每天都在做单元测试。你写了一个函数，总是要执行一下，看看功能是否正常，这，也是单元测试，这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

When

什么时候测试？单元测试越早越好，早到什么程度？TDD要求先编写测试代码，再进行开发。按照测试拟定的测试用例进行开发.

Who

由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。

单元测试应避免编写桩代码.

桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

Why

成本效率

很多研究成果表明，无论什么时候作出修改都需要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，因此从经济角度来看， 应该尽可能早的查找和修改Bug。

它是一种验证行为。

程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。

它是一种设计行为。

编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

它是一种编写文档的行为。

单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

它具有回归性。

自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

How

对于经验丰富的人,他们通常都能够洞察出系统哪些方面最可能出现问题,然后集中地对这些方面进行测试;但是如果不具备那么多经验的话,要想发现这些可能出问题的bug,将会相当困难且令人沮丧.但是另一方面,最终的用户通常能够发现我们的bug,让我们非常难堪,这同时给职业升迁带来极大的不利.

Right-BICEP

• Right----结果是否正确
• B----是否所有的边界条件都是正确的
• I----能查一下反向关联吗
• C----能用其他手段交叉检查一下结果吗
• E----你是否可以强制错误条件发生
• P----是否满足性能要求

Right

测试的结果是否正确.但是在代码的整个生命周期中,"正确"的定义可能会不断在变;但是无论如何,你至少需要确