单元测试本质：面向逻辑块

    单元测试是最先阶段的软件测试，面对的目标最小，能够综合使用黑盒测试方法和白盒测试方法，按理说，单元测试用例的设计应该是最简单的，但实际上，单元测试用例的设计常让人感受无从下手，这是什么缘由？是代码真的不具备“可测性”吗？仍是测试思路和方法不对？正确的测试思路和方法是什么？单元测试工具应该具有什么样的功能，才能支持快速地构建测试用例？

    大道至简，意思是掌握了事物的本质，事情就会变得很简单。反之，若是事情很复杂很麻烦，每每表示没有抓住本质。

    单元测试的本质是什么？首先要看单元测试的目标是什么。单元测试检测代码功能逻辑，实现高质高效的编程。只要真正作过单元测试的工程师都知道，单元测试要作的，能作的，就是检测代码的功能逻辑，扯上其余东西是没有任何意义的。既然单元测试是对代码功能逻辑的检测，那么，测试用例要作的，就是针对代码的功能逻辑，设定其输入，并判断其输出是否符合预期，从而检测功能逻辑的正确性。功能逻辑是由什么实现的？逻辑块。因此，单元测试的本质，是面向逻辑块，单元测试用例的本质，是逻辑块的输入输出，也就是设定逻辑块的各类可能输入，及对应的预期输出。

    一旦咱们把目光转向逻辑块，全部的事情就会变得简单。来看一个典型示例。“典型”的意思是，若是这个代码不会测，实际项目也就不会测，由于一样的测试问题会大量存在；反过来，若是这个代码能够测得很好很快，那么实际项目的测试就基本上没有问题，由于已经掌握了正确的测试思路和测试方法。这个代码的功能是，取得职位列表，将职位标题拼成短信并发送给用户。参数是一个数据流，包含用户的手机号和想要什么类型的职位等信息，程序从数据库里读取对应的职位列表和一个映射表，映射表用来检查哪些职位已经发送给用户，而后把职位的标题拼成短信而且发送给用户。代码使用C++编写，但它所表达的测试问题和测试思想，则是通用的。

   
   

    请想想，这个代码的测试思路是什么？也就是说，哪些变量要设置输入，哪些变量要判断输出？若是按照传统的方法，输入是参数，输出是返回值，那基本无法测。可是若是面向逻辑块（上面的代码分为两张图片，第二张图片实现函数的功能逻辑，也就是咱们要测的逻辑块），马上就有了思路：输入是链表对象objList和映射表对象map里的数据，输出是拼接出来的字符串，在两个地方须要判断它的值。

    具有了面向逻辑块的测试思路，就能够将“可测性”这个词扔进垃圾桶了，除非代码真的糟糕得太过度，不然都不难测。至于代码之间的耦合，那是再正常不过的事情，代码反映了客观事物，客观事物自己就是互相关联的，代码能没有耦合？若是一个函数有多个逻辑块，一样很简单，各个逻辑块分别测试就是了。

    面向逻辑块，测试用例的数据也很简单，由于逻辑计算涉及到的数据每每不多，且通常是基本类型。上面的示例，数据算是比较麻烦的，多数代码的测试数据量都少于这个示例。虽然这个示例的数据看起来很吓人，又有链表，又有映射表，但实际上，逻辑计算中涉及到的输入就是一些标题(title)，字符串而已，也就是说，咱们要加入到链表和映射表中的对象指针，无论它的类型多复杂，每一个对象只须要设定标题(title)就OK了。至于输出，也不过是字符串。总之，对于这个示例，用例的输入是一系列字符串，输出也是一些字符串。

    传统单元测试思想，是面向函数，即用例由函数的输入输出构成，这在一些特例中没有问题，例如三角形函数、排序函数之类最底层函数。这些函数，只有一个逻辑块，且逻辑块的输入输出，与函数的输入输出彻底一致，固然可使用函数的输入输出来构建测试用例。传统的单元测试用例设计技术，都拿这些特例做为基础，当面对含有耦合关系的代码时，反而做为特例来处理，要使用编写桩代码、设置模拟对象之类的麻烦方法来解决（实际上不少时候解决不了问题，例如，前面示例中的输出怎么办？）。实际项目中，代码存在耦合关系是常态，彻底没有耦合的代码反而不多。这种拿特例当常态，拿常态当特例的方法，在本质上是错误的，所以必然很麻烦，从根本上形成了单元测试难度大、成本高。总之，面向函数来设计单元测试用例，测试将很困难，至于主张单元测试要面向对象、面向模块，那纯粹是胡扯。

    有了面向逻辑块的测试思想，测试思路是很简单了，可是，如何设置逻辑块的输入值和输出值呢？逻辑块的输入，除了参数、成员变量之类的常规变量，还包括底层输入，即调用底层函数得到的输入，如前面示例中的链表和映射表对象中的数据；不少时候，还包括局部输入，即在被测试代码执行过程当中对某些变量的实时赋值，如局部静态输入、中断输入、界面输入等。逻辑块的输出，除了返回值、成员变量之类的常规变量，还包括局部输出，即被测试代码执行过程当中对某些变量的实时判断，如前面示例中直接发送出去的短信须要在发送前实时判断。这些问题，偏偏代表了单元测试的另外一个简单：选择工具很简单。若是工具不能直接地、方便地设定逻辑块的输入输出，那基本上无法用，或者成本很高（至少十倍以上），所以，选择工具的最主要指标，就是可否直接地、方便地设定逻辑块的输入输出。C/C++单元测试工具Visual Unit 4能够经过在表格中填写数据，直接设定逻辑块的输入输出，例如前面的示例，使用Visual Unit 4，只要点点鼠标，在表格中填写一些字符串，就能够构建出链表和映射表中的数据，以及判断所拼接的短信是否正确。

    也许有人认为，对于前面的示例，若是面向函数，经过设定参数来得到链表和映射表的数据，也能够达到一样的测试效果，甚至能够同时检测代码所调用的其余函数，例如用于解析用户信息的GetUserInfo ()函数，用于从数据库读取职位列表的GetJobList()函数。这种想法是彻底错误的，白白浪费时间和精力，为何？
    一、这些函数可能尚未实现，这在并行开发中很常见；
    二、这些函数或者它们所依赖的函数在测试时可能被隔离，这在大型项目中很常见；
    三、相关设备在测试时可能不存在，例如，单元测试通常不链接数据库；
    四、相关设备没法返回测试须要的数据，例如，一个取环境温度的底层函数，老是返回固定值；
    五、即便以上问题都不存在，经过设置参数来间接得到逻辑块的输入也可能很是困难，例如前面的示例，必须熟悉通信协议，了解GetUserInfo ()函数的工做过程，并在参数中填写正确的数据流，且数据库里有合适的数据，才可能得到链表和映射表中的数据。

    面向逻辑块，则彻底不须要考虑这些问题，不管多大的项目，不管多少人并行开发，均可以在开始编写代码时，就作到边开发边测试。至于底层函数，谁家的孩子谁抱，应该由编写者直接进行测试，这样才能全面地检测它的功能逻辑。

    总之，单元测试应该面向逻辑块，只有这样，才能迅速产生测试思路，才能快速构建用例数据，才能检测功能逻辑的方方面面，不留死角，而判断一个单元测试工具是否能够高效地应用于实际项目，最主要的指标是可否直接地、方便地设置逻辑块的输入输出。