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

Question

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

最终的解决方案将是一个可用的命令解析器或远程登录到目标板。我有一个使用标准输入的完全工作的 flex bison 实现。

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

我希望能够向解析器(一个命令)提供一个“常量字符串”，然后测试在应用程序中调用了相应的命令(在应用程序 stub 中)。

我不知道如何为此设置 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 代码，只有 Bison 语法。

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();

我试图通过我不知道如何驾驶 Bison ( yyparse() 或类似的东西)来理解文档。

谁能给我一个提示？

/米凯尔

Answer 1

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

首先，它值得总结所要求的内容。 Cunit is a unit testing library 允许对 C 代码进行检测以进行自动化单元测试。单元测试通常是在没有用户界面的情况下测试代码单元。 Flex 和 Bison 是用于构建基于语言的界面的工具。

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

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

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

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

Is there working example of flex + bison with input from string, not file?

How to make YY_INPUT point to a string rather than stdin in Lex & Yacc (Solaris)

how to use yy_scan_string in lex

how to parse from a string rather than a file

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

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