单元测试是最早阶段的软件测试，面对的目标最小，可以综合使用黑盒测试方法和白盒测试方法，按理说，单元测试用例的设计应该是最简单的，但实际上，单元测试用例的设计常让人感觉无从下手，这是什么原因？是代码真的不具有“可测性”吗？还是测试思路和方法不对？正确的测试思路和方法是什么？单元测试工具应该具备什么样的功能，才能支持快速地构建测试用例？
大道至简，意思是掌握了事物的本质，事情就会变得很简单。反之，如果事情很复杂很麻烦，往往表示没有抓住本质。
单元测试的本质是什么？首先要看单元测试的目标是什么。单元测试检测代码功能逻辑，实现高质高效的编程。只要真正做过单元测试的工程师都知道，单元测试要做的，能做的，就是检测代码的功能逻辑，扯上其他东西是没有任何意义的。既然单元测试是对代码功能逻辑的检测，那么，测试用例要做的，就是针对代码的功能逻辑，设定其输入，并判断其输出是否符合预期，从而检测功能逻辑的正确性。功能逻辑是由什么实现的？逻辑块。所以，单元测试的本质，是面向逻辑块，单元测试用例的本质，是逻辑块的输入输出，也就是设定逻辑块的各种可能输入，及对应的预期输出。
一旦我们把目光转向逻辑块，所有的事情就会变得简单。来看一个典型示例。“典型”的意思是，如果这个代码不会测，实际项目也就不会测，因为同样的测试问题会大量存在；反过来，如果这个代码可以测得很好很快，那么实际项目的测试就基本上没有问题，因为已经掌握了正确的测试思路和测试方法。这个代码的功能是，取得职位列表，将职位标题拼成短信并发送给用户。参数是一个数据流，包含用户的手机号和想要什么类型的职位等信息，程序从数据库里读取对应的职位列表和一个映射表，映射表用来检查哪些职位已经发送给用户，然后把职位的标题拼成短信并且发送给用户。代码使用C++编写，但它所表达的测试问题和测试思想，则是通用的。
请想一想，这个代码的测试思路是什么？也就是说，哪些变量要设置输入，哪些变量要判断输出？如果按照传统的方法，输入是参数，输出是返回值，那基本没法测。但是如果面向逻辑块（上面的代码分为两张图片，第二张图片实现函数的功能逻辑，也就是我们要测的逻辑块），立刻就有了思路：输入是链表对象objList和映射表对象map里的数据，输出是拼接出来的字符串，在两个地方需要判断它的值。
具备了面向逻辑块的测试思路，就可以将“可测性”这个词扔进垃圾桶了，除非代码真的糟糕得太过分，否则都不难测。至于代码之间的耦合，那是再正常不过的事情，代码反映了客观事物，客观事物本身就是互相关联的，代码能没有耦合？如果一个函数有多个逻辑块，同样很简单，各个逻辑块分别测试就是了。
面向逻辑块，测试用例的数据也很简单，因为逻辑计算涉及到的数据往往很少，且一般是基本类型。上面的示例，数据算是比较麻烦的，多数代码的测试数据量都少于这个示例。虽然这个示例的数据看起来很吓人，又有链表，又有映射表，但实际上，逻辑计算中涉及到的输入就是一些标题(title)，字符串而已，也就是说，我们要加入到链表和映射表中的对象指针，不管它的类型多复杂，每个对象只需要设定标题(title)就OK了。至于输出，也不过是字符串。总之，对于这个示例，用例的输入是一系列字符串，输出也是一些字符串。
传统单元测试思想，是面向函数，即用例由函数的输入输出构成，这在一些特例中没有问题，例如三角形函数、排序函数之类最底层函数。这些函数，只有一个逻辑块，且逻辑块的输入输出，与函数的输入输出完全一致，当然可以使用函数的输入输出来构建测试用例。传统的单元测试用例设计技术，都拿这些特例作为基础，当面对含有耦合关系的代码时，反而作为特例来处理，要使用编写桩代码、设置模拟对象之类的麻烦方法来解决（实际上很多时候解决不了问题，例如，前面示例中的输出怎么办？）。实际项目中，代码存在耦合关系是常态，完全没有耦合的代码反而很少。这种拿特例当常态，拿常态当特例的方法，在本质上是错误的，因此必然很麻烦，从根本上造成了单元测试难度大、成本高。总之，面向函数来设计单元测试用例，测试将很困难，至于主张单元测试要面向对象、面向模块，那纯粹是胡扯。
