有了面向逻辑块的测试思想，测试思路是很简单了，但是，如何设置逻辑块的输入值和输出值呢？逻辑块的输入，除了参数、成员变量之类的常规变量，还包括底层输入，即调用底层函数获得的输入，如前面示例中的链表和映射表对象中的数据；很多时候，还包括局部输入，即在被测试代码执行过程中对某些变量的实时赋值，如局部静态输入、中断输入、界面输入等。逻辑块的输出，除了返回值、成员变量之类的常规变量，还包括局部输出，即被测试代码执行过程中对某些变量的实时判断，如前面示例中直接发送出去的短信需要在发送前实时判断。这些问题，恰恰表明了单元测试的另一个简单：选择工具很简单。如果工具不能直接地、方便地设定逻辑块的输入输出，那基本上没法用，或者成本很高（至少十倍以上），因此，选择工具的最主要指标，就是能否直接地、方便地设定逻辑块的输入输出。C/C++单元测试工具Visual Unit 4可以通过在表格中填写数据，直接设定逻辑块的输入输出，例如前面的示例，使用Visual Unit 4，只要点点鼠标，在表格中填写一些字符串，就可以构建出链表和映射表中的数据，以及判断所拼接的短信是否正确。
也许有人认为，对于前面的示例，如果面向函数，通过设定参数来获得链表和映射表的数据，也可以达到同样的测试效果，甚至可以同时检测代码所调用的其他函数，例如用于解析用户信息的GetUserInfo ()函数，用于从数据库读取职位列表的GetJobList()函数。这种想法是完全错误的，白白浪费时间和精力，为什么？
1、这些函数可能还没有实现，这在并行开发中很常见；
2、这些函数或者它们所依赖的函数在测试时可能被隔离，这在大型项目中很常见；
3、相关设备在测试时可能不存在，例如，单元测试一般不连接数据库；
4、相关设备无法返回测试需要的数据，例如，一个取环境温度的底层函数，总是返回固定值；
5、即使以上问题都不存在，通过设置参数来间接获得逻辑块的输入也可能非常困难，例如前面的示例，必须熟悉通讯协议，了解GetUserInfo ()函数的工作过程，并在参数中填写正确的数据流，且数据库里有合适的数据，才可能获得链表和映射表中的数据。
面向逻辑块，则完全不需要考虑这些问题，无论多大的项目，无论多少人并行开发，都可以在开始编写代码时，就做到边开发边测试。至于底层函数，谁家的孩子谁抱，应该由编写者直接进行测试，这样才能全面地检测它的功能逻辑。
总之，单元测试应该面向逻辑块，只有这样，才能迅速产生测试思路，才能快速构建用例数据，才能检测功能逻辑的方方面面，不留死角，而判断一个单元测试工具是否可以高效地应用于实际项目，最主要的指标是能否直接地、方便地设置逻辑块的输入输出。
