单元测试的肥肉与骨头

        无处不在的80-20规则，在软件开发中也同样存在，例如，80%的错误存在于20%的代码中，80%的项目时间消耗在20%的代码上，当然这只是粗略的估计，不同的项目，比例可能有所不同。

那么，这20%是哪些代码呢？是功能逻辑复杂的代码，也就是算法密集的代码。一个算法密集的函数，通常要对数据仔细分类，一个判定就是一次分类，嵌套的判定更使分类次数翻番，要做到分类正确完整且处理无误，是很困难的事。遗漏一个分类，或一个分类处理不正确，就会造成错误，错误与代码行数的比值会很高，而且，只有当输入匹配时错误才能表现出来，难于在系统测试中发现。

        一个功能逻辑较简单的函数，也许代码行数不少，也有一些判定，但这些判定通常用于拦截非法输入，以及进行调度，其功能逻辑是明确的和容易理解的，错误与代码行数的比值较低，而且，通常一些很常规的输入，就可以覆盖全部功能逻辑，因此，错误也容易在系统测试中发现。

        对于程序员来说，很多代码都是敲键盘，通过编译后，再仔细看一两遍就可以了，这些代码编写速度快，错误少，调试时间也少。另一些代码，即算法密集的代码，往往是解决问题的关键，需要创造性的和缜密的思维，这些代码占用了多数的编码时间和调试时间。

        单元测试的成本与所需的数据规模正相关，即数据密集的函数，需要更多的测试时间来构建这些数据。算法密集的代码，一般不会同时数据密集，如果是，也应该将算法密集的部分分离出去形成独立函数，例如，一个函数，要对一个结构指针数组里的各个项做复杂处理，那么，这个复杂的处理过程应该独立出去，这是很容易做到的，也是一个基本的编码规范。

        算法密集的代码包含大多数错误，且难于在系统测试中完整测试，而单元测试很容易做到这一点，且构建数据的成本低廉，是单元测试的“肥肉”。其他代码或者错误较少且容易在系统测试中发现，或者构建数据的成本较高，是单元测试的“骨头”。

        对于刚开始实施单元测试的企业来说，首先应完成算法密集的代码单元的测试，做到了这一点，可以说用20%的单元测试成本达到了80%的效益。可见的、显著的效益对于刚开始实施的企业来说是至关重要的，只有这样，测试人员才能获得成就感、增强信心与兴趣，管理层才会更有力地支持，其他同事才会更积极地配合。华为推崇“先固化、再优化”，重要的是先做起来并且见到效益，以后再慢慢强化和改进，而不是一下子就要求做到如何全面和完美。