单元测试入门基础

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

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

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

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

单元测试的范畴


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

1、 它的行为和我期望的一致吗？
    这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。

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

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

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

不写测试的借口


    到这里，我们已经列举了使用单元测试的种种理由。也许，每个人都同意，是的，该做更多的测试。这种人人同意的事情还多着呢，是的，该多吃蔬菜，该戒烟，该多休息，该多锻炼……这并不意味着我们中的所有人都会这么去做，不是吗？

1、 编写单元测试太花时间了。
    我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。
    下图表摘自<<实用软件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了准备测试，执行测试，和修改缺陷所花费的时间(以一个功能点为基准)，这些数据显示单元测试的成本效率大约是集成测试的两倍，是系统测试的三倍(参见条形图)。

    术语：域测试(Field test)意思是在软件投入使用以后，针对某个领域所作的所有测试活动。
    如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：
        1）、对于所编写的代码，你在调试上面花了多少时间。
        2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。
        3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。
    回答完这些问题，你一定不再以“太花时间”作为拒绝单元测试的借口。

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页