2014-03-05 73 views
3

我有一個關於如何在單元測試中「驅動」基於flex bison的解析器掃描器的問題。flex bison掃描儀解析單元測試,如何驅動測試案例

最終的解決方案將是一個命令解析器可用或telnet到目標板。我有一個使用stdin的全功能flex bison實現。

現在我的重點是獲取命令解析器的單元測試運行。

我希望能夠爲解析器(一個命令)提供一個「常量字符串」,然後測試在應用程序(在應用程序存根)中調用相應的命令。

我不知道如何爲此設置flex和bison。請從下面的測試案例:從cmd_lexer.l

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

} 

摘錄:

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

摘錄(具有INT主要(),其中庫尼特代碼所在)

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()或類似的東西)。

任何人都可以給我一個提示嗎?

/的Mikael

回答

3

我看到這個問題已經將近一年沒有得到答覆,是OP的唯一的問題。這可能是一個有趣的問題,涵蓋了潛在的不兼容技術元素。它也包含一些不正確的斷言,導致對解決方案空間的錯誤看法。

首先它值得總結什麼被問到。 Cunit is a unit testing library,允許在C代碼上進行自動化單元測試。單元測試通常在沒有用戶界面的情況下測試代碼單元。 Flex和Bison是用於構建基於語言的界面的工具。

基於語言的界面通常使用基於文件輸入的自動化測試進行測試,而不是基於單元的測試;然而,接口調用的軟件功能可能會被單元測試。然而,單元測試可能在測試用flex和bison編寫的軟件時發揮作用。

該問題指出解析器源文件不包含任何C代碼,只包含語法。這一定是不正確的,因爲如果它只包含語法和沒有語義動作,那麼語言就什麼都不會做。解析器的運行不會有任何形式的操作,只是顯示錯誤消息或不是,這是一個用戶界面函數。爲了獲得任何價值,解析器必須調用語義動作,這些語義動作可以用某種語言編寫,通常是C.這些多重重要的C代碼可以用於單元測試。

正如問題所述,爲了使用Cunit進行單元測試,flex/bison編碼接口將不得不使用參數化輸入和輸出,而不是文件/流輸入輸出。

這可以實現。 SO上有很多其他的答案,指的是如何做到這一點(以及flex/bison手冊)。如果我們想用字符串輸入到測試中,我們可以替代字符串輸入文件輸入爲這裏討論:

  1. Is there working example of flex + bison with input from string, not file?
  2. How to make YY_INPUT point to a string rather than stdin in Lex & Yacc (Solaris)
  3. how to use yy_scan_string in lex
  4. how to parse from a string rather than a file

同樣野牛的輸出可以通過重新定義yyerror和其他可重新配置的接口來捕獲,但我不會列出討論這些問題的問題。

因此,總而言之,是的 - 這是可能的。這是否合理?我不確定。 我的感覺是有足夠的其他形式的自動化測試工具更適合基於語言的界面組件。

+0

那麼,這是OP的答案的一個很好的開始。你做了一個非常有趣的(但不完整的)最後一點。我認爲如果你真的把OP推向了正確的方向,並將重點放在這一點上,這將是一個很好的答案。那麼你能否詳細說明_automated測試工具__更適合基於_language的接口組件? – Joost

+0

@Joost我指的是測試的語言驗證套裝,我覺得這些套裝不在所要求的測試範圍之內。我試圖說「你不能從這裏到達」。至少這些評論會給讀者留下指引。 –