如何創建靈活的單元測試？

Question

我們正在使用單元測試來測試我們的項目。我們涵蓋了大部分功能，但我認爲我們的測試太脆弱了。

我想知道是否有任何特定的事情可以做，使單元測試更靈活，所以他們不會因爲錯誤的原因而中斷。

有幾個答案提到要小心嘲笑太多......那麼嘲笑的合理原因是什麼？我認爲這可能是我們的主要問題之一，但是當您的應用程序主要是一個動態的，數據庫驅動的網站時，您如何避免嘲笑？

Answer 1

這是一個有些簡單化的答案，但顯示正確的心態：

• 測試應該打破，如果以一種你所關心的行爲變化。
• 如果行爲以您不關心的方式改變，測試應繼續進行。

所以儘可能在可能的 - 沒有去巨大自己的方式 - 確保你正在測試的方法的「最終結果」，而不關心如何到達那裏。有一點需要注意的是嘲弄 - 這是非常有用的，但可以很容易地讓你的測試變得脆弱。

Answer 2

+1給Jon。說得好。

我發現在構建更多BDD風格的測試中有很多價值。那是......拒絕每類夾具的思維方式，而是去每個上下文夾具。

我還發現RhinoMocks 3.5的AAA語法更好。

那些涵蓋組織和清潔/可讀的測試。

爲了讓我的測試不那麼脆弱，我開始嘲笑。模擬框架對於剔除依賴關係是至關重要的，但是越多，模擬的測試就知道關於實現。如果實現更改（但行爲不），那麼測試不應該中斷。

Answer 3

對Jon也+1。

在典型的工程方式中，答案總是「取決於」。

我建議看看「xUnit測試模式：重構測試代碼」一書。 （在這種情況下，x = {J，N}涵蓋了Java和.NET世界，並沒有明確爲新的實際所謂的xUnit框架引用。）

正如設計模式出現在面向對象的世界，所以TDD世界中出現了模式。值得一看。

Answer 4

我發現，當我的測試中具有以下屬性，他們往往更脆

1）設置複雜正確的狀態，以測試實際的邏輯。 2）對嘲笑有很多期望。 3）測試代碼的可讀性不好。 4）一般的系統設計不佳。

要，通常通過應用SRP，尋找我們班的責任泄漏解決這些問題，我們嘗試做以下

1）更改系統設計，以減輕測試的設置。 2）使用嘲諷而不明確期望關於模擬上執行的呼叫的數量或次序。

3）處理測試代碼爲產品代碼，執行代碼，設計審查等

Answer 5

那麼是什麼 嘲弄的正當理由？我認爲這可能是 我們的主要問題之一，但是當您的 應用程序大部分是動態的，數據庫驅動的網站時，您如何獲得 遠離嘲諷？

原因嘲笑對象包括

• 目的是或使用外部資源，例如數據庫，網絡，文件系統
• 對象是一個GUI
• 對象不是[尚未]可用
• 對象行爲不確定
• 對象設置昂貴