前言
对待测函数中的某些行为打桩可以方便单元测试(UT)/功能测试(FT)的开发,但是桩打得越彻底,其能起到防护作用也会越打折扣;如果粗略地将需要维护的代码定义为边界内的话,那么原则上不鼓励对边界内的函数打桩;在一些大型系统里,由于分工明确导致边界以外的代码量远大于边界内的代码量,而边界外的接口会给边界内UT/FT的开发带来较大成本,因此对边界外的接口打桩就是很常见的操作。
在纯C语言的系统里,对函数打桩的工具比较有限,而且使用上各有优缺点,本文要阐述的只是个人在工作中对函数打桩的总结。
CMocker原理
下图为Mock以前的正式流程,待测函数为process(),而process里调用了外部接口func,func的执行结果对process的流程有影响。
CMocker的原理如下图所示,将外部接口func(),替换成桩函数func_mock(),桩函数里指定一个回调函数(*func_callback)(),该回调函数指定的行为是与测试用例相关的,当某个用例需要改变func()的行为时,就指定回调函数(*func_callback)(),这样,在待测函数process()执行到Mocker以前的func()处时,就只会执行回调(*func_callback)()里的行为,这样就实现了在不同测试用例里指定不同行为的效果。
而对原有的业务代码里外部接口func -> func_mock的替换,实际上是通过头文件中定义宏来实现的隐式替换
#define func func_mock
从外表来看业务代码并未被修改过,这点很重要,原则上待测代码应该与正式运行时的代码相同,才能保证UT/FT防护的有效性。