大约有两周没有更新博客了，记忆中这么长时间不更新博客的也没有几次。最近烦心的事情很多，项目压力大，家里这边装修烦心的事情就更多了，劳体劳心啊。但这里想说的既不是项目也不是装修，而是另一间令人很是气愤和鄙视的事情-一件关于政府事业单位公开招聘人员的事情。

上周日，碰巧在街上遇到了一位好朋友A，A给我讲了这么一件事，让我也很是气愤。从A那得知，前段时间辽宁省举行了一次"省政府所属事业单位公开招聘人员"的考试，估计就是那种类似公务员的考试，只不过是省一级别的。A在沈的一家单位做软件开发，收入也属于中等，A这个人比较不懈于为政府部门做事，平时聊天的时候，他也总说到：如果进入政府那种地方，整个人就会变得"堕落"了。这次是A的GF’强迫’他报的名，报的是省政府位于市区的一处信息中心的职位。也许是"无心插柳柳成荫"的缘故，再加上A的基础较好，在首轮笔试中，A取得了第二名的成绩，顺利进入下一轮。A当初没想到自己能进入面试，当事实摆在面前时，A打算继续在他GF面前展示他的能力- 向其GF证明他可以。到这为止：一切看起来很美丽。

A和我说：在面试之前还要进行一轮资格审查，通过资格审查的考生才能拿到进入面试的准考证。A兴致勃勃的在规定的时间到了"资格审查"的地方，按规定在外面排队，等待"召唤"。他抱怨说：当天的天气很差，北风足有5-6级，卷夹着尘土，这么差的天气，组织方也不让考生到室内排队，而是依旧在外面被大风蹂躏。在忍受了大约30多分钟后，他被叫了进去。审查人员询问了A报考的职位后，让A出示学位证和学历证书，A也是国内名牌大学的高材生，很自豪的拿出了自己的证书。那个审查人员看了后，直接说出了两个字："不行"，理由：专业不对口。原来我的这位好友A在本科读的专业并不是"计算机科学与技术"，也就是说不是所谓的"科班"出身。A与那位考官说了自己的工作经历，A毕业后一直从事计算机软件开发工作，工作这么长时间了，也算是资深的计算机工程师了。但那位考官却说：没办法，只能按照上级规定。我的这位朋友A又反问那位考官：那为什么第一轮笔试之前的网上资格审查没有提出"不合格"呢？那位考官说：他们没有进行网上审查，直接都合格了。A无语，遂离开。

听完这个故事后，很多人都会指责政府部门的不作为，但是除了不作为之外，是否还有其他值得怀疑的地方呢？近两年，公务员、事业单位成为了大学生们以及很多社会在职人员眼中的"香饽饽"，为什么呢？工作不累，收入颇丰，特别是大家传闻中的"灰色收入"。按照老百姓的话就是："大米基本靠送，工资基本不动"，是逢年过节就发钱啊。这样的工作对于很多人来讲都是很具吸引力的，再加上中国传统的"官本位"思想，只要是为政府工作都是"官"，"官"的社会地位自然也高，找对象好找等等诸如此类的理由，让公务员考试一举成为国内竞争最激烈的考试之一了。上千人竞争一个职位很常见。

说远了，还是回到小A吧，听完这件事我也和小A谈了我的一些想法，我有三个假想：
1、如果类似这种考试笔试前的"资格审查"都形同虚设的话，那么政府是否有诈取考生的考试费之嫌疑呢？听小A说笔试的考试费用为50元RMB；相信大家也都听说过每年全国有大约多少人参加公务员或者中事业单位考试了吧；这里要提醒即将参加类似公务员或事业单位考试的人，千万确定、一定以及肯定的比对你所报考的职位与你的专业，如果不一致，那我看就算了吧，否则赔了银子还惹得一肚子气没地方撒；
2、如果政府只要100%的所谓专业对口人员的话，即使你专业笔试考分第一也不考虑你的话，那么政府似乎有"任人为证"的嫌疑？这会让天下所有人都感到失望的(办假证的人也许该高兴了)。我也不是科班出身，所以对这种事情很敏感并严重鄙视；要求有专业知识并不等于一定要是某专业毕业。无论是从经验还是能力我都为我的朋友A鸣不平，如果公平竞争进入面试，A拿下这个职位是没有问题的，而现在他连参考的机会都没有，就凭一句：所学专业与职位要求不符！试问：哪个领导天生就是学"做领导"这门专业的！借用一下几千年前陈胜吴广的呼声："帝王将相，宁有种乎？" 都什么年代了？还在用这种老思想、封闭守旧的思想？不知道面试的时候会不会问你家祖辈是不是贫农啊？是不是根正苗红啊？这样的单位不去也罢；
3、在小A被拿下后，其他两位同一职位的入围资格审查的人员也有被拿下的可能(小A说面试按照1:3的原则，一共三人进入资格审查阶段)，如果前三名都被拿下的话，谁递补呢？网上只是公布了前三名的成绩(当然如果你是考生你可查自己的成绩，但是你无法知道其他人的成绩)，这里似乎有漏洞，有走后门的漏洞，不能保证某大人物的亲属不"趁虚而入"，并看起来合情合理。

如果以上假想都成立的话，那是我们极其不愿意看到的。还好我的这位朋友A原本就不在乎这个职位，所以才有了上面和我的倾诉，这里写出来给想参加或即将参加类似这种考试的人以警醒。希望上述只是局部现象。

曾经在多篇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的维护任务将有很大加重，实现全工程的单元测试集中还需时日。