flex bison扫描器解析的单元测试，如何驱动测试用例

Question

我有一个关于如何在单元测试中“驱动”基于 flex bison 的解析器扫描仪的问题。

最终的解决方案将是一个可用的命令解析器或 telnet 到目标板。我有一个使用 stdin 的完全工作的 flex bison 实现。

现在我的重点是为命令解析器运行单元测试。

我希望能够为解析器（一个命令）提供一个“const 字符串”，然后测试在应用程序中（在应用程序存根中）调用了相应的命令。

我不知道如何为此设置 flex 和 bison。请在下面找到测试用例：

status_cmd_test.c:

#include "CUnit/Basic.h"
#include "cmd_stub.h"


void scan_string(const char* str);

void testSTATUS_OK(void)
{

  scan_string("status\n\0\0");
  CU_ASSERT(1 == status_sub_nrof_invokes())

}

摘自 cmd_lexer.l：

void scan_string(const char* str)
{
  YY_BUFFER_STATE buf;
  buf = yy_scan_string(str);
  yylex();
  yy_delete_buffer(buf);
}

cmd_parser.y 不包含任何 c 代码，只有野牛语法。

摘自 cmd_test.c（有 cunit 代码所在的 int main()）

if (NULL == CU_add_test(suite_p, "test of status", testSTATUS_OK))
{
  CU_cleanup_registry();
  return CU_get_error();
}

/* Run all tests using the CUnit Basic interface */
CU_basic_set_mode(CU_BRM_VERBOSE);
CU_basic_run_tests();
CU_cleanup_registry();
return CU_get_error();

我试图通过我不知道如何驱动野牛（ yyparse() 或类似的东西）来理解文档。

谁能给我一个提示？

/ 迈克尔

Answer 1

我看到这个问题已经将近一年没有答案了，并且是 OP 唯一的问题。这可能是一个有趣的问题，涵盖了潜在不兼容技术的元素。它还包含一些错误的断言，这些断言给出了解决方案空间的错误视图。

首先值得总结一下被问到的问题。Cunit 是一个单元测试库，它允许对 C 代码进行检测以进行自动化单元测试。单元测试通常是在没有用户界面的情况下测试代码单元。Flex 和 Bison 是用于构建基于语言的界面的工具。

基于语言的接口通常使用基于文件输入的自动化测试进行测试，而不是基于单元的测试；然而，接口调用的软件功能可能会进行单元测试。然而，单元测试可能在测试用 flex 和 bison 编写的软件方面发挥作用。

问题指出解析器源文件不包含任何 C 代码，只包含语法。这一定是不正确的，因为如果它只包含语法而没有语义动作，那么该语言将什么也不做。解析器的运行不会有任何动作，但会显示或不显示错误消息，这是一个用户界面功能。要获得任何值，解析器必须调用用某种语言（通常是 C）编写的语义操作。这些多个且重要的 C 代码可以用于单元测试。

正如问题中所问，要使用 Cunit 进行单元测试，flex/bison 编码接口必须使用参数化输入和输出，而不是文件/流输入输出。

这是可以实现的。关于 SO 上还有很多其他答案，它们涉及如何做到这一点（以及 flex/bison 手册）。如果我们想使用字符串输入进行测试，我们可以将字符串输入替换为文件输入，如下所述：

1. 是否有 flex + bison 的工作示例，输入来自字符串，而不是文件？
2. 如何使 YY_INPUT 指向字符串而不是 Lex & Yacc (Solaris) 中的 stdin
3. 如何在 lex 中使用 yy_scan_string
4. 如何从字符串而不是文件中解析

同样，可以通过重新定义 yyerror 和其他可重新配置的接口来捕获 bison 的输出，但我不会列出讨论这些的问题。

所以，总而言之，是的 - 这是可能的。是否合情合理。我不知道。我的感觉是有足够多的其他形式的自动化测试工具更适合基于语言的界面组件。