标签 Mock 下的文章

C单元测试之Mock Test篇

曾经在多篇blog中报怨过:用C语言写业务逻辑实在是让人身心忐忑不安,再加之C语言自有的"特点",让其与"单元测试"始终若即若离,曾经尝试过写了一个轻量级C Unit Testing lib,至少目前我依旧在用,但多用在编写独立算法以及底层库的场合。业务层少有使用。业务层多是遗留系统,当初前辈们设计时对可测性考虑不够周全,导致现在无法很好的将各个部分独立抽出进行测试,虽然我们也在做着类似"重构"的工作,但鉴于规模较大,不能一蹴而就,我们需要一步一步找出使用C应对各种单元测试情况的方法。这里说说Mock Test

在系统中,我们不可避免的要调用一些外部或者系统级别的接口,而我们在测试时这些接口的环境也许并不存在,但是我们测试业务流程时还是要覆盖到所有的,业界就提出了Mock这个概念,最开始在Java开发领域,后来在其他语言中都有引入。Mock是一种什么东西?其实感觉就是给你一个机会,一种模拟和控制外部/系统级别对象或者接口的方法,这样你大可在不必与真实环境交互的前提下就完成所有依赖外部环境的业务流程的覆盖测试。Mock Test在许多语言中都有支持,但是在C语言中,Mock的支持似乎少之又少,在Cgreen这个C Unit test framework中虽然支持Mock,但是其要求你的待测试的业务接口必须附加一个stub参数,这样具有"侵入性"的设计让我感觉很是别扭,而且对于外部接口,你更是无法改变其接口原型,那么能否有其他的方法呢?这里放出一种我的方案,也不甚完美。

C语言有其自身的特色,我这里利用的就是其在编译时的一些特色:先进行预编译,再进行编译和链接。我试着在两个阶段之间做一个trick,以达到我的目的-Mock。

一般我们这样编写一个业务模块:
/* biz.h */
#ifndef BIZ_H
#define BIZ_H

#include

int biz_operation(char *fname);
#endif

/* biz.c */
#include "biz.h"

int biz_operation(char *fname) {
        FILE *fp = NULL;

        fp = fopen(fname, "r");
        if (fp == NULL) {
                printf("fail to open fle!\n");
                return 1;
        } else {
                printf("succeed to open file!\n");
                return 0;
        }
}
这个业务模块有一个业务操作流程,试图只读方式打开一个文件。如果没有mock辅助,我们在测试时需要在环境下手工创建一个文件,这样才能返回"成功",否则一直就是"失败","成功"分支也就无法测试得到。

我们先建立我们的单元测试代码文件:
/* test.c */
#include "biz.h"

void test_biz_operation_return_succ() {
        int rv;
        rv = biz_operation("test-c-mock.txt");
        xx_assert(rv == 0);
}

int main() {
        … …
        /* 无论采用什么单元测试框架,都会有直接或者间接的类似如下调用:*/
        test_biz_operation_return_succ();
        … …
}
biz_operation依赖一个fopen的C标准库调用,我们如何去做一个fopen的mock接口呢?前面说过,我们要利用C的两阶段编译的特色来完成这个mock。我们增加一个mock.h和一个对应的mock.c,我们在这对文件中实现我们自己对fopen的控制。
/* mock.h */
#ifndef MOCK_H
#define MOCK_H

#include

FILE* mock_fopen(char *fname, char *option);
#endif

/* mock.c */
#include "mock.h"

FILE* mock_fopen(char *fname,  char *option) {
        return (FILE*)0×12345678; //在这里,你可以自由控制返回结果
}

如何将mock_fopen与fopen联系在一起呢?我们通过gcc提供的-D选项来做。我们形象化的说一下:
上述源文件的目录结构如下:
/export/home/mock_test
  - biz/
  - test/
我们在test目录下新建一个Makefile文件,用来自动完成test的编译。
## Makefile ##
BIZOBJDIR = /export/home/mock_test/biz
BIZOBJ = $(BIZOBJDIR)/mock_biz.o
BIZSRC = $(BIZOBJDIR)/biz.c

TESTSRC = test.c mock.c
TESTOBJ = test.o mock.o

MOCK_FLAG = -Dfopen=mock_fopen # 关键之处

all:
        gcc $(MOCK_FLAG) -c -o $(BIZOBJ) $(BIZSRC)
        gcc -c $(TESTSRC) -I$(BIZOBJDIR)
        gcc -o test $(TESTOBJ) $(BIZOBJ)

我们从理论上分析一下这种方法的可行性:我们先将biz.c编译成.o文件,MOCK_FLAG将biz.c中的fopen替换成了mock_fopen,这些都是预编译器的功劳;然后我们在test目录下,将test.c 和mock.c编译为对应的.o文件,这里无需使用MOCK_FLAG,否则会有compile error发生;最后一步进行链接:test.o中的biz_operation符号在mock_biz.o中被resolved,而mock_biz.o中的biz_operation在mock.o中被resolved。这样链接后,

fopen处实际上调用的是mock_fopen,也就是那个你可以自由控制的接口。如果在biz.c中还有其他系统调用,比如write, read等,我们都可以

将其mock加到mock.c中,比如称为mock_write和mock_read,然后更新MOCK_FLAG = -Dfopen=mock_fopen -Dwrite=mock_write -Dread=mock_read等。

以上结果已经在Solaris上GCC下测试通过了,目前这种想法还不成够熟,也只是在单个业务模块下做了些测试,下一步如果能做到整个工程的单元测试那就更好了。鉴于上面的情况,如果mock过多,对Makefile的维护任务将有很大加重,实现全工程的单元测试集中还需时日。

单元测试进行曲

又是老生常谈-'单元测试',说实话自己在单元测试上是'语言上的巨人,行动上的矮子',属于那种说的比做的多的人^_^。不过也不能说什么也没做。记得去年年末的时候自己还设计并实现过一个简单的'C语言单元测试包'呢^_^,至今这个包仍然还在使用呢。不过大多数的单元测试都不像想象中那样简单,我们在介绍单元测试的时候,大多拿Add、Sub等作例子,这样当然有好处,简单易懂。其实学习单元测试初期关键是学习单元测试的思想,所以这些Add、Sub也能满足需求。不过在真正的项目中,单元测试大多做起来较为困难,我是在Unix上做C开发的,Java的咱暂先不提,也没什么资格提,虽然曾经花过一段时间专心研究过,还写过些Java学习心得,但是毕竟没做过实际的项目,说起来心里也发虚。

曾经很长一段时间,自己在编码阶段基本上都是缺少单元测试的,一是项目中Legacy代码较多,耦合太紧,想把那部分代码拿出来比'登天还难'(有点夸张),反正基本上是'一扯一大帮',俗称'一个都不能少';而是部门在这方面积淀较少,在计划的时候对这方面考虑不够,时间上也不充裕,经常是在集成测试或者系统测试的时候顺便带上单元测试了,这样的后果就是'浪费'。本来在单元测试阶段发现一个Bug需要10 minutes,拖到集成测试或者系统测试后,这个时间就可能是1 hour或者 1 day 或者更多时间,这里可不是'耸人听闻',的确有真实的事例,有过这样的经历的人都体会到其中的痛苦。

痛定思痛,自己终于觉醒了。恰好,一个新的短期项目刚刚处于开发阶段,正好是发挥单元测试的大好时机。杀开一条血路,做就是了。但是不能盲目去做。单元测试是需要设计的,而且感觉单元测试设计因系统架构模式而异,有难有易;而且单元测试设计时需要考虑项目进度、测粒度和测试密度。测试粒度,也就是说你选择多大的功能单元来作为单元测试的基本单元,是函数一级的还是模块一级的;测试密度,则是你的单元测试用例的语句覆盖度有多少了。完美的单元测试是应该覆盖程序运行的每条分支的,但是要编写出这么多的单元测试用例,其工作量我想比开发这个系统的工作量只多不少,这样一来即使你能编写出这么多用例的代码,你的Leader也会对你吼的。选择关键路径覆盖是我的选择测试密度的'标准'。我们的系统的架构是基于'队列/管道架构模式'的,这也决定了我们的单元测试较容易,根据这个特点我选择我的单元测试的力度是模块一级的。基本策略就是根据模块内的关键路径设计模块级别的单元测试用例–对我们这个系统来说具体就是造各种各样的消息,放到输入队列中即可。

我的单元测试已经进行了两天多了,效果很是明显,有些bug的发现都出乎我的意料。每当测试完一个功能模块,我会感觉对这个模块更有信心了,还有一种莫名的成就感^_^。

好的单元测试最好是能自动化,这样一旦修改了代码,可以对以前测试过的代码进行回归单元测试,保证此次修改不影响到以前已经测试过的代码的正确性。不过自动化又谈何容易?Java有很好的工具支持,可谓众星捧月;C则是孤家寡人,少有有利的工具支持。这样的话,我们就需要自己写自动化的逻辑,当然这些逻辑因系统而异,至今我也很难想出好的通用的办法,比如像Mock Test这样的测试,在C中就很难实现,我们常常以真实的情景代之,而不是使用Mock,这样就可能让不同的用例对执行顺序有一个依赖,执行顺序不一致,测试的结果可能不相同。

以上的一些经验都有一定的语言局限性,对于使用C开发的系统可能有些借鉴的意义,但是对于Java开发的系统上面的很多说法也许还是误导的,大家一定要'睁大眼睛',看清楚了^_^。单元测试仍在进行中…^_^

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats