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