内容介绍

　　本系列文章根据《单元测试与VU2.6应用》视频讲座的理论部分整理而成，主要讨论四个问题：为什么需要单元测试？怎样征服可测性难题？怎样才能高效率测试？怎样保证测试效果？重点阐述单元测试的关键问题，不是一般概念，适合于对单元测试有一定了解的读者。

　　在选择工具和实施单元测试前，我们应该对相关理论有一个系统的了解，特别是将会遇到哪些难题，如何解决，要心里有数，否则的话，很可能劳民伤财，半途而废。如果只会测试加法函数或者三角形函数之类的独立小程序，就以为可以做单元测试了，那就像一个人刚学会走路，就去长途跋涉。

　　本文介绍的是针对企业项目的单元测试。企业项目具有两个特点：项目复杂，时间紧张。项目复杂，意味着测试时会遇到很多难题；时间紧张，要求我们不但要保证测试效果，还要尽可能高效率。本文不是泛泛而谈，而是针对企业项目的两个特点，努力揭示本质性的问题，并提出解决办法，对于常识性的问题，将比较简略的带过。使用的工具是Visual Unit 2.6，本文主要不是介绍工具，而是介绍问题所在和解决办法，涉及到工具，只是为了具体的展示解决办法，也为了说明，这些办法都是可行的，并非空谈。

　　第1章 为什么需要单元测试？

　　1.1 从代码特性看单元测试的必要性

　　代码有一个很基本的特性，是什么呢？对数据分类处理。一个判定，就是一次分类。如果判定中又嵌套了判定的话，分类次数就会翻倍。循环判定也是一种分类。

　　如果一个分类遗漏的话，也就是说，某种输入没有处理，会怎么样呢？一个Bug诞生了！如果一个分类的处理不正确，又会怎么样呢？又一个Bug诞生了！

　　一个函数要做到没有错误，要保证两点：分类完整，也就是各类可能输入都要考虑到；

　　处理正确，也就是每一类输入都要进行正确的处理。做到了这两点，就可以说，函数的功能逻辑是正确的。函数的功能逻辑就是对数据的分类以及处理。

　　那么，怎样才能全面地检测程序的功能逻辑呢？调试，是临时的，不做记录，另一方面，调试的工作方式是拦截数据，并不是所有输入分类都能拦截得到的，如果一个函数有十类输入，调试能覆盖五六个就不错了。系统测试，不针对具体的函数，无法做到对具体函数的输入分类覆盖。要全面地检测程序的功能逻辑，必须把输入分类全部列出来。并检测程序是否处理了这些输入，处理是否正确。这就是单元测试。