你將如何測試複雜輸出的東西？

Question

我在這個週末爲一個非平凡的語言寫了一個解析器。某些輸出可能很複雜，即使是看似簡單的輸入。假設解析器的輸入是一個數學表達式，輸出是描述輸入的元組列表。

所以輸出可能是20行。

你會如何編寫junit測試？你會運行解析器，手工檢查結果，如果看起來正確，將結果放入單元測試中作爲正確答案？

還是這只是瘋了，我需要做一些不同的事情？

Answer 1

理想情況下，「單元」測試的想法是它測試一個小功能單元。如果輸出過於複雜以至於難以測試，那就意味着你正在測試的功能太大。

請記住，除了驗證您的代碼是否正常工作外，您的單元測試還可以充當您的代碼應該如何使用的示例。一個單一的測試只是將結果與大的預定義結果進行匹配可能不會那樣做。

嘗試將內部運作分解爲更小的方法並測試每個方法。嘗試測試從較小的結果（例如，如果輸入A導致輸出Y，輸入B導致輸出Z，然後編寫一個測試，以確定輸入AB是否導致輸出YZ或任何適當的結果）。

Answer 2

這是一個完全有效的測試，但不一定是單元測試。這趨向於進行集成測試或迴歸測試：

您將如何編寫junit測試？你會運行解析器， 手動檢查結果，如果它看起來正確，將結果放入 單元測試中作爲正確答案？

使用JUnit進行集成測試和/或迴歸測試是完全有效的。我使用了很多時候描述的方法，但是您需要意識到這具有侷限性。

1. 除非您小心，否則您的測試會變得非常脆弱。例如，你的輸出可能包含意外的字符（空格，cr/lf和編碼是一個特殊的問題，如果你混合unix和windows機器）。這使測試稍微複雜一些，因爲您必須「清理」解析器的輸出。

2. 在你的junit java類中有20行文本和輸入是很痛苦的。所以你要面對在java中使用文本的選擇，並把它們放入一個單獨的文件中。大多數情況下，我發現單獨的文件更易於管理，而且這些方法只是一個單獨的文件，處理文件並將其與參考文件進行比較。

3. 因爲您正在進行集成測試，所以在遇到失敗的測試時很難確定原因。

由於JacobM說，它可能是你的測試被拆下來到更小的碎片是個好主意，但你可以保留其他的測試，因爲他們是有用的。