单元测试Cgenerating python-cod

Question

我有一个项目涉及到一些（相当简单）C代码生成作为构建系统的一部分。本质上，我有一些与项目（嵌入式C）相关的版本信息，我想在我的二进制文件中公开这些信息，这样我就可以很容易地确定为调试目的对特定设备编程的固件版本。在

我正在编写一些简单的python工具来实现这一点，我想确保它们经过了彻底的测试。一般来说，这相当简单，但我不确定代码生成部分的最佳策略是什么。基本上，我要确保生成的文件都：

• 语法上是正确的
• 包含必要的信息

第二，我可以（我相信）达到一个合理的程度与正则表达式匹配。然而，第一项任务更大。我可能可以使用类似pycparser的方法并检查结果AST来实现这两个目标，但这似乎是一个不必要的重量级解决方案。在

编辑：我的构建层次结构的数据流图

Answer 1

谢谢你的图表！因为您没有测试覆盖率，如果是我，我会编译生成的C代码，看看它是否有效：）。您没有提到您的工具链，但是在类Unix的环境中，gcc <whatever build flags> -c generated-file.c || echo 'Oops!'应该足够了。在

现在，生成的代码可能不是独立的编译单元。没问题：写一个垫片。示例shim.c：

#include <stdio.h>
#include "generated-file.c"
main() { 
    printf("%s\n", GENERATED_VERSION);  //or whatever is in generated-file.c
}

那么gcc -o shim shim.c && diff <(./shim) "name of a file holding the expected output" || echo 'Oops!'应该给你一个基本的测试。（<()是bashprocess substitution）保存预期结果的文件可能已经在git repo中，或者可以使用Python例程将其写入某个磁盘。在

编辑2即使您的实际工具链不适合自动化，这种方法也可以工作。要测试代码的语法有效性，即使目标处理器使用不同的编译器，也可以使用gcc。例如，使用gcc -ansi编译将禁用许多GNU扩展，这意味着使用gcc -ansi编译的代码比使用full on，GNU extendedgcc编译的代码更可能在另一个编译器上编译。有关您可以使用的所有不同风格（ditto C++），请参阅"C Dialect Options"上的gcc页面。在

编辑顺便说一句，这是GNU autoconf使用的相同方法：将一个小的测试程序写入磁盘（autoconf称之为conftest.c），编译它，然后查看编译是否成功。测试程序（最好）是测试是否一切正常所必需的最低限度。根据Python的复杂程度，您可能需要使用不同的垫片测试生成代码的几个不同方面。在