昨天在编译项目代码时遇到了这样一个错误：

xx_base.h:72:2: 错误：#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."

这是预编译器的错误输出。原因很明显：预编译器在处理xx_base.h时没有发现_BIG_ENDIAN或_LITTLE_ENDIAN的定义，#error预处理宏输出了如上错误。下面是出现错误位置的源码片断：

/* xx_base.h*/
#if defined(_BIG_ENDIAN)
… …
#elif defined(_LITTLE_ENDIAN)
… …
#else
#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."
#endif

xx_base.h是部门一基础库中的一个头文件，上面的做法对于基础库自身来说并无太大问题。基础库的Makefile通过检测CPU类型定义了对应的字节序宏，并在编译时作为gcc的命令行选项传入：

/* Makefile */
ifeq ($(CPU), x86)
        DEFS += -D_LITTLE_ENDIAN
else ifeq ($(CPU), sparc)
        DEFS += -D_BIG_ENDIAN
else
        $(error $(CPU) is not supported!)
endif

但是一旦这个基础库被某项目复用，且该xx_base.h文件被项目代码引用，编译就会出现问题，因为各个项目的Makefile中并没有定义_LITTLE_ENDIAN或_BIG_ENDIAN宏。如果基础库不做修改，那么复用该基础库的项目代码中就都需要考虑这两个宏的定义问题。这未免有些"强加"的意味，对于一个几乎被所有项目复用的基础库而言，这样的做法显然不妥。

那如何解决这个问题呢？一个思路是如果基础库在发布后依旧携带这些宏的定义，那就可以避免这样的问题了。在很多使用autotools(包括autoconf, automake, libtool等)协助进行代码构建的开源包中经常会看到一个名为config.h的源文件，那里面包含了与移植相关的宏定义。这个config.h是configure脚本根据config.h.in模板自动生成的。

我们的基础库如果完全用autotools改造显然也可以解决这个问题，但这样一来以前编写的一些构建脚本就要被全部抛弃，能否折中一下呢：利用autoconf生成config.h，但不输出Makefile，依旧使用原先的Makefile？

实验证明这样是可以的。只需对configure.in(或configure.ac)做一些调整即可，将类似AC_CONFIG_FILES([Makefile src/Makefile src/example/Makefile])这样的代码从configure.in中移除即可：

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.64])
AC_INIT([baselib], [1.0.0], [xx@gmail.com])

AC_CONFIG_HEADERS([include/config.h])

# Checks for header files.
AC_CHECK_HEADERS([stddef.h stdlib.h string.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_SIZE_T

# Checks for library functions.
AC_FUNC_MALLOC
AC_CHECK_FUNCS([memset])

AC_OUTPUT

AC_CONFIG_HEADERS这句是关键！修改完configure.in后，执行autoheader，我们就会在include下发现config.h.in模板文件被生成了出来。执行autoconf生成的configure脚本后，我们在include下就得到了config.h。

下面就是在config.h中加入我们期望的宏。在我们的问题中，我们希望在configure时可以探测到当前host所用的字节序(endianess)，并将结果反映到config.h中。幸运的是autoconf内置了字节序的测试宏AC_C_BIGENDIAN。增加了AC_C_BIGENDIAN测试宏的configure.in经过autoheader处理后得到的config.h.in文件中多了如下这组代码：

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
#  undef WORDS_BIGENDIAN
# endif
#endif

在Sun SPARC小机上运行configure，我们得到的config.h中有关字节序的宏定义代码如下：
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
#  define WORDS_BIGENDIAN 1
# endif
#endif

config.h中定义了WORDS_BIGENDIAN宏，说明Sun Sparc小机采用的是BigEndian。这样只要基础库的头文件都在最开始包含了config.h，那么上面的问题就解决了。

不过有些朋友不喜欢WORDS_BIGENDIAN这个宏的命名，想自己给标识字节序的宏命名，比如BASELIB_IS_BIGENDIAN。那么我们如何来支持呢？这里我也找到了一个办法：

首先，就是手工编辑config.h.in(注意这之后你就不要通过autoheader生成config.h.in了)，在结尾加上这样一行：
#undef BASELIB_IS_BIGENDIAN

然后，修改configure.in，通过AC_DEFINE来定义一个新的BASELIB_IS_BIGENDIAN宏：

AC_C_BIGENDIAN
if test $ac_cv_c_bigendian = yes; then
    AC_DEFINE(BASELIB_IS_BIGENDIAN, 1)
fi

我们通过AC_C_BIGENDIAN的检测结果来确定是否定义BASELIB_IS_BIGENDIAN宏，ac_cv_c_bigendian显然是AC_C_BIGENDIAN内置的一个变量，如果需要，我们也可以模仿其命名规则得到其他测试宏内置的变量。

最后，执行autoconf和configure，我们就可以在include/config.h的结尾看到这样一行定义：
#define BASELIB_IS_BIGENDIAN 1

AC_DEFINE不一定非要与测试宏绑定在一起，它的用法很灵活。如果我们的代码中需要根据不同操作系统的类型来调用不同的代码，那么我们需要在config.h中放置几个标识操作系统类型的宏，比如BASELIB_LINUX和BASELIB_SUNOS。和BASELIB_IS_BIGENDIAN一样，我们首先需要手工编辑config.h.in，增加如下两行代码：

#undef BASELIB_LINUX
#undef BASELIB_SUNOS

然后，修改configure.in，加入自定义的OS测试代码，并且定义对应的宏：

os=`uname -s`
case $os in
    Linux)
        AC_DEFINE(BASELIB_LINUX, 1)
        ;;
    SunOS)
        AC_DEFINE(BASELIB_SUNOS, 1)
        ;;
    *)
        AC_ERROR([host is unsupported.])
        ;;
esac

最后，执行autoconf和configure。如果我们在redhat上，我们就会在config.h中看到如下代码：

#define BASELIB_LINUX 1
/* #undef BASELIB_SUNOS */

autoconf也内置了一系列系统类型测试宏，比如AC_CANONICAL_SYSTEM(依赖install-sh、config.sub和config.guess三个脚本)，其测试后的结果放在了$host变量中，你也可以通过判断$host变量来确定到底在config.h中定义哪个宏。

Behaviour-Driven Development，即行为驱动开发在业界早已不是什么新鲜玩意了。我之前也略有了解，不过一直没有"深入钻研"。直到今年年初InfoQ的几篇有关BDD的文章才让我对BDD有了更多的认识。与TDD一样，C语言在BDD领域依旧是一个"后进分子"，在多数主流语言(Java，C#，Ruby等)都已经拥有比较成熟的BDD框架(如JBehave、SpecFlow和Cucumber)的今天，C语言却似乎仅有一款BDD框架-CSpec可用。于是年初的时候我就把设计和实现一个用于C语言的行为驱动开发框架加入到我今年的ToDoList中了。

在确定好目标的同时，我也给这款框架命名为CBehave(模仿JBehave)，并在Google Code上建立了CBehave的托管项目。但人的时间和精力总是有限的，直到8月中旬我才开始着手进行这个框架的设计和实现。设计和实现一款给程序员使用的工具，这本身就是一件让人兴奋的事情。我先是通过DanNorth的博文"Introducing BDD"(其中译版在这里)了解了BDD的"诞生历程"，然后又广泛地了解了一下其他语言的BDD框架。对于CSpec这一目前唯一的C语言BDD框架，我并不想给予过多评价，不过总体来说和其他语言的BDD框架相比，CSpec有些简陋，应该说还无法很好的支持BDD中一些核心思想的表达，并且目前它还不支持Mock。这些都坚定了我重新实现一个C语言BDD框架的决心，起码我不完全是"重新发明轮子"^_^。

作为后来者，CBehave的设计参考了诸多现有的主流BDD框架，其中直接灵感来源于Cucumber，不过由于C语言静态编译语言的本质，CBehave与Cucumber在大多地方也只是形似而已。作为一篇CBehave的介绍性文章，这里列举一些CBehave的主要特点：

首先，CBehave借鉴Cucumber的设计采用Feature + Scenario结合的方式来描述功能需求(DanNorth: 需求也是行为)，并且在每个Scenario内部采用BDD的经典的GIVEN-WHEN-THEN结构描述行为的验收标准(acceptance criteria)。

这里给出一个总体的行为描述模板：

FEATURE #1
    SCENARIO #1
        GIVEN
            … …
        WHEN
            … …
        THEN
            … …

    SCENARIO #2
        GIVEN
            … …
        WHEN
            … …
        THEN
            … …

    … …

FEATURE #2
… … 

FEATURE #n

原则上FEATURE之间是相互隔离的；FEATURE内部的多个Scenario之间在代码定义和执行时也是相互隔离，互不干扰的。这是一个使用该框架的基本约束。不过这就好比建议性锁，全靠使用时的自觉，否则很容易造成框架运行出错。

下面是一个真实的使用CBehave对strstr函数进行测试的例子(代码片断，完整例子参见源码cbehave/src/example/string_test.c)：

FEATURE(1, "strstr")
    SCENARIO("The strstr finds the first occurrence of the substring in the source string")

        GIVEN("A source string: [Lionel Messi is a great football player]")
            char *str = "Lionel Messi is a great football player";
        GIVEN_END

        WHEN("we use strstr to find the first occurrence of [football]")
            char *p = strstr(str, "football");
        WHEN_END

        THEN("We should get the string: [football player]")
            SHOULD_STR_EQUAL(p, "football player");
        THEN_END

    SCENARIO_END

    SCENARIO("If strstr could not find the first occurrence of the substring, it will return NULL")

        GIVEN("A source string: FC Barcelona is a great football club.")
            char *str = "FC Barcelona is a great football club";
        GIVEN_END

        WHEN("we use strstr to find the first occurrence of [AC Milan]")
            char *p = strstr(buf, "AC Milan");
        WHEN_END

        THEN("We should get no string but a NULL")
            SHOULD_STR_EQUAL(p, NULL);
        THEN_END
    SCENARIO_END
FEATURE_END

int main() {
    cbehave_feature strstr_features[] = {
        {feature_idx(1)},
    };

    return cbehave_runner("Strstr Features are as belows:", strstr_features);
}

编译运行这个测试，我们会得到如下结果(节选)：

Strstr Features are as belows:

Feature: strstr
 Scenario: The strstr finds the first occurrence of the substring in the source string
  Given: A source string: Lionel Messi is a great football player
  When: we use strstr to find the first occurrence of [football]
  Then: We should get the string: [football player]
 Scenario: If strstr could not find the first occurrence of the substring, it will return NULL.
  Given: A source string: FC Barcelona is a great football club.
  When: we use strstr to find the first occurrence of [AC Milan]
  Then: We should get no string but a NULL

Summary:
 total features: [1]
 failed features: [0]
 total scenarios: [2]
 failed scenarios: [0]

CBehave将strstr的行为原汁原味地输出到最终的测试结果中，与xUnit等框架相比，这确是一个进步，我们在获知测试结果的同时，还依稀中看到了这个特性的需求描述，前提是你要给出一个很好很精确的描述，但这已经不是框架可以帮助你做的了^_^。另外即使你的测试失败了，你甚至可以不通过错误提示中的源码文件名和行号信息也可以快速定位到错误的位置所在。因为错误周围是有足够的上下文信息的。

其次，CBehave支持mock。CBehave中mock的实现完全参考了我之前设计的单元测试框架LCUT，下面是一个简单的例子(片断，完整代码参加cbehave/src/example/product_database_test.c)：

FEATURE(1, "Get the total count of employees")
    SCENARIO("Get the total count of employees")
        GIVEN("The db connection is ready and there are 5 employees in total");
            CBEHAVE_RETV_RETURN(connect_to_database, 0×1234);
            CBEHAVE_ARG_RETURN(table_row_count, 5);
            CBEHAVE_RETV_RETURN(table_row_count, 0);
        GIVEN_END

        WHEN("We call function: get_total_count_of_employee");
            int count = get_total_count_of_employee();
        WHEN_END

        THEN("The total count of employees we read from db should be 5")
            SHOULD_INT_EQUAL(count, 5);
        THEN_END

    SCENARIO_END
FEATURE_END

最后，CBeahve还支持多种SHOULD_XX宏，并且可根据需要灵活添加。目前已支持整型、字符串以及布尔类型的判定。

关于CBehave的实现历程这里也简单说一下。

首先需要确定CBehave的"长相"，也就是CBehave采用的行为描述模板是啥样子的。这块儿确是花了我不少的时间，查看各种资料以及研究其他框架的设计，最终选择了Feature+Scenario以及用Given-When-Then来描述行为的"文档模板"。

其次，有了"文档模板"后如何将其转换为可执行的代码实体？这块也费了我不少脑细胞。思前想后，最终设计是将Feature转换成一个可运行的实体-函数。另外我在函数中使用{}来物理划分Scenario，{}可以隔离变量的可见性和作用域，已达到多个Scenarios定义和执行互不干扰的目的。

上面的标准文档结果中的一个FEATURE宏展开后的样子大致是这样的：

static void cbehave_feature_n(void *_state) {
    cbehave_state _old_state;
    cbehave_feature_entry(…, &_old_state, _state);

    {
        /* Scenario #1 */
        int _scenario_state = 0; \
        cbehave_scenario_entry(x, _state);

        … …
        cbehave_scenario_exit(&_scenario_state, _state);
    }

    {
        /* Scenario #2 */

    }

    … …
    {
        /* Scenario #n */

    }

_feature_over: \
    cbehave_feature_exit(…);
}

关于feature函数的命名，我考虑了很长时间，由于从外界输入的信息无法约束，这里我引入了Feature序号，并同时将序号作为Feature函数名的一部分。例如：
FEATURE(10, "fopen features")
展开后的feature函数名就是cbehave_feature_10，这样做对用户也有一定约束，但约束较小，只需CBehave用户保证各个Feature的序号不同即可。

在使用CBehave时，很可能出现另外一个问题:那就是测试代码在GIVEN或WHEN区段中依赖的一些资源申请或其他代码的初始化可能失败或出现异常。遇到这种情况时，用户多选择return或exit。但一旦用户这样做，CBehave就无法统计和输出测试失败情况或统计的不够准确了。为了尽量保证CBehave统计的精确性，CBehave提供了一个宏FEATURE_RETURN供用户使用。FEATURE_RETURN将控制权转移到Feature函数的末尾，也就是上面宏展开末尾的哪个_feature_over跳转标识符处，这样Feature有机会把这一错误情况记录下来。另外还可以保证其他Feature测试的继续运行。这里举个简单例子(完整代码参见cbehave/src/example/text_editor_test.c)：

FEATURE(1, "Text Editor – Open Exsited File")
    SCENARIO("Open an Exsited File and write something to it")

        GIVEN("A file named foo.txt")
            FILE *fp = NULL;
            char *buf = "Hello Cbehave!";
        GIVEN_END

        WHEN("we open the file and write something to it")
            fp = fopen("foo.txt", "r+");
            if (!fp)
                FEATURE_RETURN(errno);
        WHEN_END

        THEN("We should see [Hello Cbehave] has been written into foo.txt")
            if (fp)
                fclose(fp);
        THEN_END
    SCENARIO_END
FEATURE_END

例子中如果fopen打开foo.txt失败，代码中调用了FEATURE_RETURN来应对这一情况，而不是直接调用return或exit。

最后，与LCUT不同，Cbehave会尝试运行完所有Feature的测试，而不是遇到测试错误就停止运行。

因为之前有过LCUT单元测试框架的设计和实现经验，这次CBehave框架的设计和实现就相对容易了些。CBehave的设计用了一天时间，上周末两天"百忙"中抽空完成了编码和测试，目前已提供了cbehave-0.1.0-beta版供下载体验，欢迎大家提出你的宝贵意见和建议^_^，更多关于CBehave使用方面的细节请参考CBehave用户指南(http://code.google.com/p/cbehave/wiki/CBehave_User_Guide_cn)。

BTW，我并不是一个纯粹的TDDers。我个人认为完全采用TDD或是BDD还是有一定局限的。是否采用这些方式进行开发还要视产品(或项目)的时间、质量、人员能力等诸多制约因素而定。个人推断国内的C程序员多普遍缺乏采用框架进行单元测试的意识，BDD或TDD的推广还是任重道远的。