什么是单元测试_单元测试的目的是什么

什么是单元测试

工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。

单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

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

对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。我认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈我的看法。

一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以我的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。

有一种看法是，只测试类的接口（公有函数），不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写（inline函数），所有在源文件编写实现的函数都要进行测试（构造函数和析构函数除外）。

单元测试之测试目的

首先保证代码质量。

其次保证代码的可维护。

再此保证代码的可扩展。

目的之一代码的代码质量。

我们编写的代码虽然可以通过编译器检测到语法的正确性质，但并不能保证代码逻辑也是正确的。我们该怎么保证代码执行是正确的呢。好下面我们来看下代码。

java 代码

int add（int x， int y）{

return x+y;

}

上面的功能模块。下面是段测试代码

java 代码

void testAdd（）{

//我们要求程序逻辑是1＋4＝5；

assertEquals（5，add（1，4）;

}

经过测试以后，如果你修改了int add（int x， int y）;里面的逻辑，如果修改的正确，测试代码始终都是见到绿色的。如果你逻辑错了。那不好意思，你的测试将会让你重新写那段逻辑代码。直到你正确为止。

有个比较特殊的情况，如果我测试代码写成这样，那我保证逻辑代码的正确性，但我却看不到我期待的绿色，这有是什么原因呢？

java 代码

void testAdd（）{

//我们要求程序逻辑是1＋4＝5；

assertEquals（6，add（1，4）;

}

我个人认为这个问题并是逻辑代码的问题，而是你测试代码中的逻辑问题，噢，MyGot，作为程序员的我。已经为逻辑代码伤脑筋了。还要为测试代码烦恼，做人真命苦啊。 想来也确实是这样。

这就引申了另外一个问题，怎么样才可以保证我逻辑代码的可测性？

目的之二代码的可维护性。

就拿上面的例子来说吧。只要我们的单元测试是正确的，那我们就可以保证无论你怎么修改那段代码，只要测试代码可以产生绿色条，那OK，你修改的逻辑代码是正确的。当然可维护并非只有这点，还有，比如保证修改了这段代码不会影响到其他的模块等。

目的之三代码的可扩展。

对于这点我理解很肤浅。只能表达表面的东西，希望。

对于可扩展我觉得保遵循一个代码之间的耦合度降到最低。就OK了。单元测试对这方面有很强的好处，为了程序的可维护性，它可以强迫你写低耦合度的程序。

单元测试的优点

1、它是一种验证行为。

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

2、它是一种设计行为。

编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计

成易于调用和可测试的，即迫使我们解除软件中的耦合。

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

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

4、它具有回归性。

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

单元测试的范畴

如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。

1、 它的行为和我期望的一致吗？

这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。

2、 它的行为一直和我期望的一致吗？

编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一 致时，你需要确认：在任何情况下，这段代码是否都和你的期望一致；譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。

3、 我可以依赖单元测试吗？

不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。

4、 单元测试说明我的意图了吗？

单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。