所有的單元測試都應該成功嗎？

Question

假設您製作的應用程序嘗試將字母A中的內容儘可能密切地轉換爲字母B。

因爲B語言非常複雜，所以這並不總是成功的。但你確實得到了一個近似的音譯。

考慮到你期望20-30％失敗，你將如何在這種情況下建立單元測試？

Answer 1

它必須始終是您的單元測試成功的目標。您使用它的方式不能區分軟件中的嚴重錯誤和您期望的翻譯錯誤。

我會建議分開兩個：

1. 使用單元測試只是爲了確保你的軟件運作的，你希望它（即使這包括在翻譯一些錯誤）
2. 生產測試的方式數據集包含由您的軟件生成的翻譯。您可以手動檢查此測試數據集，也可以使用R等統計軟件包來了解翻譯質量。

Answer 2

預計失敗的單元測試不是單元測試。您需要通過使用充當過濾器的評估函數來更改成功的定義，並決定它是否「足夠接近」並確定合格/不合格。隨着您的翻譯者變得更好，您可以在過濾器中提高欄。

Answer 3

單元測試應該是確定性的。失敗的測試應該表明軟件失敗，而不是「按預期工作」。對於您的情況，準備數據的方式可以確保結果並對它們進行測試，無論轉換是成功還是失敗（考慮到您對的期望失敗，測試失敗總是一個選項 - 重要的是您始終處於控制之下當你的測試通過/失敗）。

Answer 4

我在這種情況下學到的技術只是測試功能（或確定性）的代碼部分。當然，如果將確定性與非確定性部分分開，則是困難的部分。這種簡單的說法是「將[或重構]簡化爲功能性」，這意味着將代碼中確定性的部分分開，然後對這些部分進行測試。

對於上下文的情景位，讀這blog一篇關於此技術的應用程序時，讓周圍的遺留代碼測試（以及使用名爲ApprovalTests開源單元測試庫）。

另一種可能感興趣的技術是「基於理論」的​​測試。有關更多信息，請查看blog。

Answer 5

單元測試可能失敗的唯一原因是涉及時序（主要是在電子元件正在測試的情況下）。但是，即使這些情況，應該從單元測試中去除時間問題，例如，通過延長/切換超時或其他時間問題，如果可能的話。當不可能的時候，應該記錄良好。

另一種消除計時問題並使測試具有確定性的方法是使用一些注入方法爲所有外部接口編寫存根，即能夠設置外部接口方法將返回的值。通過以這種方式設置單元測試，您可以從字面上測試每個錯誤情況。（故事：我在一家公司工作，其中幾個單元測試偶爾會失敗，只有少數人能夠分析這些是嚴重錯誤還是時機問題。這將節省很多時間以便在單元測試中進行良好的單元測試第一名）。