单位测试实施解惑(二)

2020-04-12  阅读次数:

  在这个新的单位测试依次中,我们不需为正常情况的测试做甚么任务(这里做了必然方法的简化,实践的单位测试仍需求我们就正常情况停止更加过细的考验),只是让dll_pop_head函数正常任务,前去不为null的节点就好了。要让dll_pop_head函数前去null的话,报答地向INJECTION_POINT_DLL_POP_HEAD注入点经过error_inject函数注入毛病。error_inject函数的第一个参数是注入点;第二个参数是所注入的毛病码(我们约定0表现没有毛病),该码作为调用injected_error_get函数的前去值;第三个参数是所需注入的数据,该数据经过injected_error_get函数的第二个参数前去。

  其次,在产品代码中由UNIT_TESTING宏所控制的代码其实不需求有固定的格局,可以依据需求对毛病点的行动停止定义。比如,能够对链表模块停止毛病注入时,我们只欲望影响链表1的行动,而不想对链表2有任何影响,如许的话可以将欲望影响链表的指针注入到毛病点中(此时需求定义一个数据结构,以便error_inject函数能传递多个参数),固然dll_pop_head函数中由UNIT_TESTING所控制的代码也得做响应的调剂,使其在前去null前检查以后的链表指针(即_p_dll参数)与所注入的指针可否相反。

  为了能对象malloc如许的函数也添加毛病注入点,我们需求对之停止封装。比如,供给osal_malloc函数,并在个中添加毛病注入点所需的代码。采取这类方法的结果是,我们需求很薄的一个平台层。可否是跨平台完整取决于项目标特色。打个比如,关于基于VxWorks及时操作系统的项目,假设平台的编译开辟是在Linux主机上的话,则所供给的平台层应完成跨VxWorks和Linux操作系统。切切不要忘了,此时单位测试应在Linux主机上完成,而非VxWorks上。而关于一个构建Linux应用软件的项目来讲,假设开辟也是在Linux主机上完成的话,平台层就基本不需求思考跨平台后果。

  引入平台层以后,读者或许会有两个担心:一是,跨平台库的开辟需求少量的时间;二是,跨平台的代码又若何做单位测试?关于第一个担心,我的说明是:项目所应用的操作系统或C库的系统函数具有极强的收敛性,数量很有限,与传统单位测试所采取打桩的方法比拟,我置信构建如许的平台层的任务量要小很多。至于第二个后果,我的建议是:因为平台层做得很薄,功用复杂,我们可以保持对之做单位测试。此时,单位测试的核心应放在构建于平台之上的软件模块上。

  至此,毛病注入方法的单位测试方法引见完了。或许还有读者会问,这又不打桩,也将毛病点处理代码嵌入在产品代码中,这照样单位测试吗?实践上,单位测试的目标是为了让被测代码的各行和各分支能运转到以确保质量,只需到达这一目标,可否打桩或在产品代码中嵌入测试代码并不是介定是否是单位测试的关键条件。我们应时辰记住,开辟活动中的行动应是价值驱动的,而非方法驱动的。一个没有价值的行式,注定是糜费,也必然会束缚思维让我们在困境中难以找到打破的门路。价值驱动的不美观念常常会让我们抛开束缚,取自得想不到的后果。