嘲笑還是不嘲笑？

Question

據我所知，從極限編程和單元測試中，測試必須由另一個開發人員在另一個開發測試方法之前完成（或者來自相同的開發人員，但測試必須在方法實現之前編寫）。

好吧，看起來不錯，我們只需要測試一個方法是否具有良好的行爲，當我給它一些參數。

但理論和實踐之間的區別在於，在理論上不存在但在實踐中有...

的第一次，我試圖測試，我發現它在某些情況下很難由於對象之間的關係。我發現嘲笑的做法，我發現它非常有用，但一些概念讓我懷疑。

首先，嘲諷隱含的說：「你知道該方法如何運行，因爲你必須知道它需要什麼其他對象......」。那麼，從理論上講，這是我的朋友鮑勃寫的測試，他只知道，當我給它「john」字符串時，該方法必須返回true ...這是我使用dao代碼訪問數據庫而不是使用散列表在內存中...

我的可憐的朋友Bob會如何寫測試？他會期待我的工作......

好吧，似乎不是純粹的理論，但無論如何。但是，如果我看看很多模擬框架的文檔，它們允許我測試一個方法被調用的次數和順序！ ouch ...

但是，如果我的朋友鮑勃必須測試這種方法，以確保良好的依賴關係，方法必須寫在測試之前，不是嗎？

哼...幫助我的朋友鮑勃...

我們什麼時候停止使用模擬裝置（爲了驗證等）？ 當模擬機制有用嗎？ 理論，實踐和模擬：什麼是最好的平衡？

Answer 1

您的描述中似乎缺少的是將合同與實施分離的概念。在C＃和Java中，我們有接口。在C++中，僅由純虛函數組成的類可以填充此角色。這些並不是真的必要，但有助於建立邏輯分離。因此，除了您似乎遇到的困惑之外，練習應該更像是：Bob爲一個特定類/功能單元編寫單元測試。在這樣做的時候，他爲其他類/單元定義了一個或多個接口（合同），以支持這個接口。他現在不需要寫這些東西，而是用模擬對象填充它們以提供他的測試和被測系統所需的間接輸入和輸出。因此，一組單元測試的輸出不僅僅是驅動單個單元開發的測試，還需要其他代碼支持正在開發的單元需要執行的合同。

Answer 2

我不確定究竟是什麼問題。所以我可能無法準確回答這個問題，但我會試一試。

假設你正在書寫系統中，其中一個需要獲取數據（假設爲簡單起見String）從供應商，然後逆該字符串，並將其發送到另一個系統下

B和C提供給你，他們實際上是接口，現實生活中的實現可能是BImpl和CImpl。

爲了您的工作目的，您知道，您需要從系統B調用readData（），並從系統C調用sendData（String）。您的朋友Bob也應該知道，您不應該發送你得到它之前的數據。此外，如果你得到「abcd」，你應該發送「dcba」

看起來你和Bob都應該知道這一點，他寫測試，然後編寫代碼......問題在哪裏？

當然現實生活是比較複雜的，但你應該仍然能夠用單元測試的簡單交互來建模。

Answer 3

當你正在編寫一個單元測試時，你正在測試結果和/或測試中的類別的行爲，結果和/或行爲是否與預期的相符。

期望會隨着你開發這個類的時間而改變 - 新的需求可能會在這種改變中產生類的行爲或者調用特定方法的結果。它永遠不會成爲石頭和單元測試，並且被測試的類將一起演變。

最初，您可能會從一個非常精細的級別開始幾個基本測試，然後演變成越來越多的測試，其中一些測試可能對測試的類的實際實現非常特殊（至少如就該類別的可觀察行爲而言）。

在某種程度上，您可以針對被測試類中的原始存根編寫出很多測試，這會產生預期的行爲，但大多尚未實現。然後你可以重構/開發「真實」的課程。

在我看來，儘管在開始時編寫所有的測試，然後全面開發課程，但這是一個夢想 - 根據我的經驗，測試和受測試的課程一起演變。 也可以由也由同一個開發者編寫。

然後，我當然不是TDD純粹主義者，只是試圖以務實的方式充分利用單元測試。

Answer 4

我不確定我是否理解你的問題。

使用mock驗證對象之間的協作。例如，假設您有一個使用用戶名和密碼的Login（）方法。現在假設您想要此方法嘗試登錄失敗的登錄。在你的單元測試中，你將創建一個模擬記錄器對象，並設置它將被調用的期望。然後，您會依賴注入到您的登錄類中，並使用錯誤的用戶名和密碼調用您的Login方法來觸發日誌消息。

您單元測試工具包中的其他工具是存根（stub）。當你不測試協作時使用存根，而是僞造依賴關係，以便讓測試的類可以運行。

羅伊Osherove，該單元測試的藝術的作者，有嘲笑好的視頻：TDD - Understanding Mock Objects

此外，我建議去他的網站http://artofunittesting.com/和下看右側的免費視頻標題爲「單元測試視頻」。