单元测试的范畴 

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

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

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

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

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

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

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

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

    不写测试的借口

    到这里，我们已经知道了使用单元测试的种种理由。但目前的实际情况是大多数程序员不进行单元测试，或只进行简单的单元测试。下面是一些他们常用的接口：

    1、 编写单元测试太花时间了。

    我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：

    1）、对于所编写的代码，你在调试上面花了多少时间。
    2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。
    3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。
    回答完这些问题，你一定不再以“太花时间”作为拒绝单元测试的借口。

    2、 运行测试的时间太长了。

    合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。

    3、 测试代码并不是我的工作。

    你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。

    4、 我并不清楚代码的行为，所以也就无从测试。

    如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢?

    5、 但是这些代码都能够编译通过。

    我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。

    6、 公司请我来是为了写代码，而不是写测试。

    公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。

    7、 如果我让测试员或者QA（Quality Assurance）人员没有工作，那么我会觉得很内疚。

    你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。

    8、 我的公司并不会让我在真实系统中运行单元测试。

    我们所讨论的只是针对开发者的单元测试。也就是说，如果你可以在其他的环境下（例如在正式的产品系统中）运行这些测试的话，那么它们就不再是单元测试，而是其他类型的测试了。实际上，你可以在你的本机运行单元测试，使用你自己的数据库。

    总而言之，单元测试会让我们的开发工作变得更加轻松，让我们对自己的代码更加自信。无论是大型项目还是小型项目，无论是时间紧迫的项目还是时间宽裕的项目，只要代码不是一次写完永不改动，编写单元测试就一定超值，它已成为我们编码不可缺少的一部分。

黄剑父 2009-07-15 21:19 发表评论

黄剑父 2009-06-14 22:01 发表评论