大道至简，意思是掌握了事物的本质，事情就会变得很简单。反之，如果事情很复杂很麻烦，往往表示没有抓住本质。
单元测试的本质是什么？首先要看单元测试的目标是什么。单元测试检测代码功能逻辑，实现高质高效的编程。只要真正做过单元测试的工程师都知道，单元测试要做的，能做的，就是检测代码的功能逻辑，扯上其他东西是没有任何意义的。既然单元测试是对代码功能逻辑的检测，那么，测试用例要做的，就是针对代码的功能逻辑，设定其输入，并判断其输出是否符合预期，从而检测功能逻辑的正确性。功能逻辑是由什么实现的？逻辑块。所以，单元测试的本质，是面向逻辑块，单元测试用例的本质，是逻辑块的输入输出，也就是设定逻辑块的各种可能输入，及对应的预期输出。
一旦我们把目光转向逻辑块，所有的事情就会变得简单。来看一个典型示例。“典型”的意思是，如果这个代码不会测，实际项目也就不会测，因为同样的测试问题会大量存在；反过来，如果这个代码可以测得很好很快，那么实际项目的测试就基本上没有问题，因为已经掌握了正确的测试思路和测试方法。这个代码的功能是，取得职位列表，将职位标题拼成短信并发送给用户。参数是一个数据流，包含用户的手机号和想要什么类型的职位等信息，程序从数据库里读取对应的职位列表和一个映射表，映射表用来检查哪些职位已经发送给用户，然后把职位的标题拼成短信并且发送给用户。代码使用C++编写，但它所表达的测试问题和测试思想，则是通用的。
请想一想，这个代码的测试思路是什么？也就是说，哪些变量要设置输入，哪些变量要判断输出？如果按照传统的方法，输入是参数，输出是返回值，那基本没法测。但是如果面向逻辑块（上面的代码分为两张图片，第二张图片实现函数的功能逻辑，也就是我们要测的逻辑块），立刻就有了思路：输入是链表对象objList和映射表对象map里的数据，输出是拼接出来的字符串，在两个地方需要判断它的值。
具备了面向逻辑块的测试思路，就可以将“可测性”这个词扔进垃圾桶了，除非代码真的糟糕得太过分，否则都不难测。至于代码之间的耦合，那是再正常不过的事情，代码反映了客观事物，客观事物本身就是互相关联的，代码能没有耦合？如果一个函数有多个逻辑块，同样很简单，各个逻辑块分别测试就是了。
面向逻辑块，测试用例的数据也很简单，因为逻辑计算涉及到的数据往往很少，且一般是基本类型。上面的示例，数据算是比较麻烦的，多数代码的测试数据量都少于这个示例。虽然这个示例的数据看起来很吓人，又有链表，又有映射表，但实际上，逻辑计算中涉及到的输入就是一些标题(title)，字符串而已，也就是说，我们要加入到链表和映射表中的对象指针，不管它的类型多复杂，每个对象只需要设定标题(title)就OK了。至于输出，也不过是字符串。总之，对于这个示例，用例的输入是一系列字符串，输出也是一些字符串。
传统单元测试思想，是面向函数，即用例由函数的输入输出构成，这在一些特例中没有问题，例如三角形函数、排序函数之类最底层函数。这些函数，只有一个逻辑块，且逻辑块的输入输出，与函数的输入输出完全一致，当然可以使用函数的输入输出来构建测试用例。传统的单元测试用例设计技术，都拿这些特例作为基础，当面对含有耦合关系的代码时，反而作为特例来处理，要使用编写桩代码、设置模拟对象之类的麻烦方法来解决（实际上很多时候解决不了问题，例如，前面示例中的输出怎么办？）。实际项目中，代码存在耦合关系是常态，完全没有耦合的代码反而很少。这种拿特例当常态，拿常态当特例的方法，在本质上是错误的，因此必然很麻烦，从根本上造成了单元测试难度大、成本高。总之，面向函数来设计单元测试用例，测试将很困难，至于主张单元测试要面向对象、面向模块，那纯粹是胡扯。
有了面向逻辑块的测试思想，测试思路是很简单了，但是，如何设置逻辑块的输入值和输出值呢？逻辑块的输入，除了参数、成员变量之类的常规变量，还包括底层输入，即调用底层函数获得的输入，如前面示例中的链表和映射表对象中的数据；很多时候，还包括局部输入，即在被测试代码执行过程中对某些变量的实时赋值，如局部静态输入、中断输入、界面输入等。逻辑块的输出，除了返回值、成员变量之类的常规变量，还包括局部输出，即被测试代码执行过程中对某些变量的实时判断，如前面示例中直接发送出去的短信需要在发送前实时判断。这些问题，恰恰表明了单元测试的另一个简单：选择工具很简单。如果工具不能直接地、方便地设定逻辑块的输入输出，那基本上没法用，或者成本很高（至少十倍以上），因此，选择工具的最主要指标，就是能否直接地、方便地设定逻辑块的输入输出。Visual Unit 4可以通过在表格中填写数据，直接设定逻辑块的输入输出，例如前面的示例，使用Visual Unit 4，只要点点鼠标，在表格中填写一些字符串，就可以构建出链表和映射表中的数据，以及判断所拼接的短信是否正确。
也许有人认为，对于前面的示例，如果面向函数，通过设定参数来获得链表和映射表的数据，也可以达到同样的测试效果，甚至可以同时检测代码所调用的其他函数，例如用于解析用户信息的GetUserInfo ()函数，用于从数据库读取职位列表的GetJobList()函数。这种想法是完全错误的，白白浪费时间和精力，为什么？
1、这些函数可能还没有实现，这在并行开发中很常见；
2、这些函数或者它们所依赖的函数在测试时可能被隔离，这在大型项目中很常见；
3、相关设备在测试时可能不存在，例如，单元测试一般不连接数据库；
4、相关设备无法返回测试需要的数据，例如，一个取环境温度的底层函数，总是返回固定值；
5、即使以上问题都不存在，通过设置参数来间接获得逻辑块的输入也可能非常困难，例如前面的示例，必须熟悉通讯协议，了解GetUserInfo ()函数的工作过程，并在参数中填写正确的数据流，且数据库里有合适的数据，才可能获得链表和映射表中的数据。
面向逻辑块，则完全不需要考虑这些问题，无论多大的项目，无论多少人并行开发，都可以在开始编写代码时，就做到边开发边测试。至于底层函数，谁家的孩子谁抱，应该由编写者直接进行测试，这样才能全面地检测它的功能逻辑。
总之，单元测试应该面向逻辑块，只有这样，才能迅速产生测试思路，才能快速构建用例数据，才能检测功能逻辑的方方面面，不留死角，而判断一个单元测试工具是否可以高效地应用于实际项目，最主要的指标是能否直接地、方便地设置逻辑块的输入输出。
原文链接：http://www.kailesoft.com/article/329.html
