作爲大學項目的一部分，我們必須編寫玩具語言的編譯器。爲了做一些測試，我正在考慮如何寫最好的單元測試。由於編譯器是用haskell編寫的，Hunit和quickcheck都可用，但可能不太合適。編譯器輸出的單元測試
我們該如何做任何一種非手動測試？ 我唯一的想法是有效地編譯爲haskell，看看輸出是什麼，並使用一些shell腳本將它與編譯程序的輸出進行比較 - 這是相當多的工作，並不是太優雅。
單元測試是爲了幫助我們，而不是評估工作本身的一部分。
這真的取決於你編寫的編譯器的哪些部分。如果你可以保持不同的階段來幫助隔離問題，但是在任何階段，甚至在集成級別上，由單元測試組成的源代碼和手工編譯代碼是完全合理的。您可以從最簡單的法律程序開始，並確保您的編譯器輸出與手動編譯時相同的內容。
隨着複雜性的增加以及手工編譯變得笨拙，編譯器會保留它所做的某種記錄是有幫助的。然後，您可以查閱此日誌以確定是否針對給定的源程序啓動特定的轉換或優化。
根據您的語言，您可能會考慮從程序片段集合中產生隨機程序（在QuickCheck靜脈中）。這個生成器可以測試你的編譯器的穩定性，並能夠處理潛在的不可預見的輸入。
單元測試應測試一小段代碼，通常是一個類或一個函數。詞彙和語義分析將分別進行單元測試。 Intermediate Represetation生成器也將有自己的測試。
單元測試包含一個簡單的測試用例：它調用函數在受控環境中進行單元測試並驗證（斷言）函數執行的結果。單元測試通常只測試一個行爲，並具有以下結構，稱爲AAA：
一旦程序輸出到控制檯（如標準輸出），測試變得更加困難。那麼你不得不求助於一些外部工具，如grep或expect來檢查輸出。
保持數據結構中函數的返回值的時間儘可能長。如果你的編譯器的輸出是彙編代碼，那麼在內存中建立一個字符串（或者一個字符串列表）並在最後的時刻輸出它。這樣你可以更直接，更快速地測試字符串的內容。
看一看shelltestrunner。這裏有一些example tests。它也被用於this compiler project。
一種方法是使用this guy is doing來測試真正的編譯器：和儘可能多的人一起討論，然後你們每個人編譯並運行相同的程序集，然後比較輸出結果。一定要添加每個使用的測試用例，因爲更多的輸入使得它更有效。有一點自動化和源代碼控制的樂趣，你可以使它很容易維護。
一定要讓教授先行，但因爲你只會分享測試用例和輸出，所以我沒有看到他有什麼空間可以反對。
你不需要編譯成Haskell，你也可以編寫一個簡單的解釋器參考實現。 – sclv 2010-11-21 01:56:19