checkmk - 云端在线

程序：

您的姓名

checkmk - 用于生成用于检查单元测试的 C 单元测试的 awk 脚本
框架。

概要

检查表 [ 清洁模式=1 [ 输入文件 ]

商品描述

生成包含用于检查单元测试的单元测试的 C 语言源文件
框架。 这个脚本的目的是自动化一些典型的样板文件
使用 Check 编写测试套件时必须编写：具体来说，是
SRunner、Suite(s) 和 TCase(s)，以及这些对象之间关系的构建
和测试功能。

该工具旨在供熟悉检查单元测试的人使用
框架。 本手册将假定您熟悉该框架。

Check 框架及其相关信息可在
http://check.sourceforge.net/ <网址：http://check.sourceforge.net/>.

输入文件 争论 检查表 使用一个简单的、类似于 C 预处理器的语法来声明
测试函数，并在 Check 中描述它们与套件和 TCase 的关系。
检查表 然后使用此信息自动编写一个 主（） 函数包含所有
必要的声明，以及运行测试套件所需的任何代码。 这
最终的 C 语言输出被打印到 检查表的标准输出。

提供了将用户代码插入生成的工具 主（） 功能，
提供使用日志记录、测试装置或专门的退出值。

虽然可以省略 输入文件 争论 检查表 并提供输入文件
on 检查表的标准输入，通常建议将其作为
争论。 这样做允许 检查表 要知道文件的名称，将引用放置到
它在 C 语言输出的初始注释中，并穿插 C #line 指令
在整个过程中，通过将用户引导到原始位置来方便调试问题
输入文件。

配置

唯一官方支持的选项是指定一个真值（使用 Awk 的定义
对于 "true") 变量 清洁模式。 这导致 检查表 不放置合适的
源代码中的 #line 指令，有些人可能会发现这些指令是不必要的混乱。

作者建议不要使用此选项，因为它会导致 C 编译器和
调试工具引用自动生成的输出中的行，而不是
原始输入文件到 检查表. 这将鼓励用户编辑输出文件
而不是原始输入文件，会使智能编辑器或
IDE 拉出正确的文件进行编辑，并可能导致修复被覆盖
当输出文件重新生成时。

#line 指令在标准上提供输入文件时自动抑制
输入而不是作为命令行参数。

基本 例

在最基本的形式中，输入文件可以只是一个序言和一个测试函数。
在第一个测试函数之前出现的任何东西都在序言中，并且将
逐字复制到输出中。 测试函数以以下形式的一行开始：

#TEST 测试名称

其中 测试名称 是您的测试函数的名称。 这将用于命名 C 函数，
所以它必须是一个有效的 C 标识符。

这是一个小而完整的示例：

--------------------------------------------------
/* 一个完整的测试示例 */

＃包括

#测试the_test
国际数控;
const char msg[] = "\n\n 你好，世界！\n";

nc = printf("%s", msg);
ck_assert(nc == (大小(味精) - 1)); /* 用于终止 NUL。 */
--------------------------------------------------

如果将上述内容放入名为 basic_complete.ts 并使用
以下命令：

$ 检查表 basic_complete.ts > basic_complete.c

basic_complete.c 将包含类似于以下内容的输出：

--------------------------------------------------
/*
* 请勿编辑此文件。 由 checkmk 生成。
* 改为编辑原始源文件“in”。
*/

＃包括

/* 一个完整的测试示例 */

＃包括

START_TEST（the_test）
{
国际数控;
const char msg[] = "\n\n 你好，世界！\n";

nc = printf("%s", msg);
ck_assert(nc == (大小(味精) - 1)); /* 用于终止 NUL。 */
}
结束_测试

int main（void）
{
Suite *s1 = suite_create("核心");
TCase *tc1_1 = tcase_create("核心");
SRunner *sr = srunner_create(s1);
国际NF;

Suite_add_tcase(s1, tc1_1);
tcase_add_test(tc1_1, the_test);

srunner_run_all(sr, CK_ENV);
nf = srunner_ntests_failed(sr);
srunner_free(SR);

返回 nf == 0 ？ 0 : 1;
}
--------------------------------------------------

在实际使用中， basic_complete.c 还将包含#line 指令。

指示 概要

这是所有理解的 C 预处理器风格指令的完整总结
by 检查表. 请参阅下面的更多细节。

＃ 测试 测试名称
# 测试信号(信号) 测试名称
# 测试退出（退出代码) 测试名称
# 测试循环（开始, 结束) 测试名称
# 测试循环信号（信号, 开始, 结束) 测试名称
# 测试循环退出（退出代码, 开始, 结束) 测试名称
#套房 测试套件名称
# 案例 测试用例名称
# 主预
# 主帖

所有指令都不区分大小写。 行首可能出现空格
# 之前，# 和指令之间，指令和任何参数之间，以及
在行尾。

测试定义 指令

以下是可用于定义测试的指令的更详细说明
函数及其容器。

测试 职能
＃ 测试 测试名称
# 测试信号(信号) 测试名称
# 测试退出（退出代码) 测试名称
# 测试循环（开始, 结束) 测试名称
# 测试循环信号（信号, 开始, 结束) 测试名称
# 测试循环退出（退出代码, 开始, 结束) 测试名称

这些是创建用于输入的模板的最基本指令 检查表。 他们是
唯一需要的指令：必须至少有一个 #test* 指令
出现在模板中，或 检查表 将失败并显示错误消息。 考试*
指令可以被指定多次，每一个都开始一个新测试的定义
功能。

测试名称 参数将用作 C 语言中测试函数的名称
输出，所以它必须是一个有效的 C 标识符。 也就是说，它必须以字母开头
字符或下划线 (_)，后跟可选的字母数字字符和/或
下划线。

也允许使用通用字符名称（在 C99 中引入），格式为 \uXXXX 或
\UXXXXXXXX，其中 X 代表十六进制数字。

指定相同是错误的 测试名称 在多个 #test* 指令中，无论
它们是否与不同的测试用例或套件相关联。

请参阅 CHECKMK IDENTIFIERS 以获取应避免用作的标识符列表
测试函数名称。

测试 SUITES
#套房 测试套件名称

该指令指定测试套件的名称（套件 检查测试中的对象
框架），所有未来的测试用例（及其测试功能）将被添加到其中。

测试套件名称 是一个文本字符串，并且可能包含任何类型的字符（其他
而不是 ASCII NUL 字符，以及将终止指令的换行符）。 任何
测试套件名称中将省略前导或尾随空格。

启动一个新的测试套件也会启动一个新的测试用例，其名称与新的测试用例相同
测试套件。 此测试用例名称可能会被后续的 #tcase 指令覆盖。

请注意 套件 对象实际上不会被定义 检查表 在 C 输出中，除非它
在某个时间点后跟 #test 指令（没有干预 #suite）。 它不是
#suite 没有关联的 #test 的错误； #suite（以及任何相关的
#tcase's) 根本不会导致任何行动 检查表 （因此将是
无用）。

#suite 指令指定相同（区分大小写）套件多个是错误的
次，除非之前的使用没有被至少一个实例化
关联的#test 指令。

如果您没有在第一个 #test 指令之前指定 #suite 指令， 检查表
执行与隐式 #suite 指令等效的操作，将字符串“Core”作为
的价值 测试套件名称 （这也意味着“核心”测试用例对象）。 这是
在上面的基本示例中进行了演示。

测试 機箱
# 案例 测试用例名称

该指令指定测试用例的名称（案例 检查测试中的对象
框架），所有未来的测试功能都将添加到其中。

#tcase 的工作方式与#suite 非常相似。 这 测试用例名称 是一个文本字符串，
并且可能包含任意字符； 和一个 案例 对象实际上不会被定义，除非
它后面跟着一个关联的#test 指令。

#tcase 指令指定相同的（区分大小写）测试用例是错误的
多次，除非以前的使用没有被至少存在实例化
一个相关的#test 指令。

另请参阅上面描述的#suite 指令。

USER 守则 IN 主要的（）

的C 主（） 由自动生成 检查表, 定义必要的 赛跑者的，
套件的，和 案例是用户指定的测试定义指令所必需的。

在大多数情况下，这完全自动化 主（） 原样很合适。 然而，
在某些情况下，人们可能希望将自定义代码添加到 主（）。 例如，
如果用户希望：

· 通过更改测试超时值 tcase_set_timeout(),

· 通过指定 Check 的“no-fork-mode” srunner_set_fork_status(),

· 为一些测试用例设置测试装置，通过 tcase_add_checked_fixture()
or tcase_add_unchecked_fixture(),

· 为套件运行器设置测试日志，通过 srunner_set_log() or srunner_set_xml()或

· 在测试套件运行后执行自定义总结。

出于这些目的，提供了 #main-pre 和 #main-post 指令。

主要的（） 序幕
# 主预

此指令后面的文本将逐字放入生成的正文中
主（） 函数，就在 检查表自己的局部变量声明，并且在任何测试之前
运行已经发生（实际上，甚至在测试之间的关系之前，测试
案例，并且已经设置了测试套件，尽管这一事实应该没有太大区别）。
自 检查表 刚刚完成声明，这是允许的，即使
根据严格的 1990 ISO C 指南，在此处进行自定义变量声明。

与前面描述的指令不同，#main-pre 最多可以指定一次。 它
前面不能有 #main-post 指令，也不能有 #suite、#tcase 或 #test 指令
可能会出现在它之后。

#main-pre 是调整设置或设置测试装置的好地方。 当然，为了
要做到这一点，你需要知道什么名字 检查表 已用于实例化 赛跑者的，
套件的，和 案例的。

支票 身份标识
指向 套件使用模式 s 声明X，其中 X 是一个数字，开始于
1，并且为每个后续#suite 指令递增。 s1 始终存在，并且
包含由第一个 #test 指令声明的测试函数。 如果该指令是
前面没有#suite，它将被命名为“Core”。

指向 案例使用模式 tc 声明X_Y，其中 X 对应于
用于名称的编号 套件 这将包含这个 案例;和 Y 是一个数字
每个新的从 1 开始 套件, 并且每增加一个 案例 在那里面 套件.

一个指向 赛跑者 使用标识符 sr 声明； 还有一个名为的整数
nf 保存测试失败的次数（在测试运行后）。

出于显而易见的原因，用户不应尝试在 主（）,
或定义任何宏或测试函数，其名称可能与局部变量冲突
使用的名称 检查表. 总而言之，这些名称是：

sX

tcX_Y

sr

NF。

主要的（） 结语
# 主帖

虽然用处不大， 检查表 还提供了一个 #main-post 指令来插入自定义
代码在最后 主（）, 测试运行后。 这可以用来清理
在序言中分配的资源，或打印有关失败的信息
测试，或提供自定义退出状态代码。

请注意，如果您使用此指令， 检查表 将 不能 提供返回语句：
您需要自己提供一个。

#main-post 指令后面不能跟任何其他识别的指令
检查表.

综合 例

现在你已经获得了各种指令的详细描述，让我们看看它
所有这些都通过这个相当全面的模板付诸实施。

--------------------------------------------------
#include "mempool.h" /* 定义 MEMPOOLSZ，原型
mempool_init() 和 mempool_free() */

无效 *内存池；

无效的mp_setup（无效）
{
mempool = mempool_init(MEMPOOLSZ);
ck_assert_msg(mempool != NULL, "无法分配内存池。");
}

无效mp_teardown（无效）
{
内存池释放（内存池）；
}

/* 序言结束 */

#suite 内存池

#tcase MP 初始化

#测试mempool_init_zero_test
内存池 = 内存池初始化（0）;
ck_assert_msg(mempool == NULL, "分配了一个零大小的内存池！");
ck_assert_msg(mempool_error(), "零分配没有错误。");

/* "MP Util" TCase 使用检查夹具。 */
#tcase MP 实用程序

#测试mempool_copy_test
无效 *cp = 内存池复制（内存池）；
ck_assert_msg(cp != NULL, "无法执行内存池复制。");
ck_assert_msg(cp != mempool, "复制返回原始指针！");

#测试mempool_size_test
ck_断言（mempool_getsize（内存池）== MEMPOOLSZ）；

#main-pre
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, "mplog.txt");

#主帖子
如果（nf ！= 0）{
printf("嘿，出问题了！%d 次整个测试失败！\n", nf);
}
返回0； /* Harness 检查输出，总是返回成功
不管。 */
--------------------------------------------------

将其插入 检查表，我们将得到大致如下所示的输出：

--------------------------------------------------
/*
* 请勿编辑此文件。 由 checkmk 生成。
* 改为编辑原始源文件“comprehensive.ts”。
*/

＃包括

#include "mempool.h"

无效 *内存池；

无效的mp_setup（无效）
{
...
}

无效mp_teardown（无效）
{
...
}

/* 序言结束 */

开始_测试(mempool_init_zero_test)
{
...
}
结束_测试

开始_测试（mempool_copy_测试）
{
...
}
结束_测试

开始_测试（内存池大小测试）
{
...
}
结束_测试

int main（void）
{
Suite *s1 = suite_create("Mempool");
TCase *tc1_1 = tcase_create("MP 初始化");
TCase *tc1_2 = tcase_create("MP Util");
SRunner *sr = srunner_create(s1);
国际NF;

/* 用户指定的预运行代码 */
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, "mplog.txt");

Suite_add_tcase(s1, tc1_1);
tcase_add_test(tc1_1, mempool_init_zero_test);
Suite_add_tcase(s1, tc1_2);
tcase_add_test(tc1_2, mempool_copy_test);
tcase_add_test(tc1_2, mempool_size_test);

srunner_run_all(sr, CK_ENV);
nf = srunner_ntests_failed(sr);
srunner_free(SR);

/* 用户指定的运行后代码 */
如果（nf ！= 0）{
printf("嘿，出问题了！%d 次整个测试失败！\n", nf);
}
返回0； /* Harness 检查输出，总是返回成功
不管。 */
}
--------------------------------------------------

使用 onworks.net 服务在线使用 checkmk