问题
I have a question about how to "drive" a flex bison based parser scanner in a unit test.
The final solution will be a command parser available or telnet to a target board. I have a fully working flex bison implementation using stdin.
Right now my focus is on getting a unit test running for the command parser.
I would like to be able to provide a "const string" to the parser (a command) and then test that the corresponding command is invoked in the application (in a application stub).
I do not know how to setup flex and bison for this. Please find the test case below:
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())
}
Excerpt from 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 does not contain any c-code, only bison grammar.
Excerpt from cmd_test.c (has the int main() where the cunit code is located)
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();
I have tried to understand the documentation by I do not know how to drive bison ( yyparse() or something like that).
Can anyone give me a hint?
/ Mikael
回答1:
I see this question has remained unanswered for nearly a year and is the OP's only question. It's possibly an interesting question covering elements of potentially incompatible technologies. It also contains some incorrect assertions that give a false view of the solution space.
First its worth summarising what is being asked. Cunit is a unit testing library that permits the instrumentation on C code for automated unit testing. Unit testing is usually testing code units in the absence of a user interface. Flex and Bison are tools used to construct language based interfaces.
Language based interfaces are usually tested using file input based automated testing, rather than unit based testing; however the software functions invoked by the interface might be unit tested. Yet unit testing may have a role in testing software written with flex and bison.
The question states that the parser source file does not contain any C code, only grammar. This must be incorrect, because if it contained only grammar and no semantic actions then the language would do nothing. The running of the parser would have no action of any kind but display an error message or not, which is a user interface function. To have any value a parser must invoke semantic actions which would be written in some language, often C. These multiple and important piece of C code could be instrumented for unit testing.
As asked in the question, to unit test with Cunit, the flex/bison coded interface would have to use parameterised input and output instead of the file/stream input output.
This can be achieved. There are quite a few other answers on SO that refer to how this can be done (as well as the flex/bison manuals). If we want to test using string input we can substitute string input for file input as discussed here:
- 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
Similarly the output of bison can be captured by redefining yyerror and other reconfigurable interfaces, but I wont list the questions that discuss those.
So, in summary, yes - it is possible. Is it sensible. I'm not sure. My feeling is there are enough other forms of automated testing tools more suited to language based interface components.
来源：https://stackoverflow.com/questions/22205557/unit-test-of-flex-bison-scanner-parse-how-to-drive-the-test-case