如何構造具有依賴關係的單元測試？

考慮下面簡單的例子：如何構造具有依賴關係的單元測試？

class MathObject(object): 
    """ A completely superfluous class. """ 
    def add(self, a, b): 
     return a + b 

    def multiply(self, a, b): 
     result = 0 
     for _ in range(b): 
      result = self.add(result, a) 
     return result

顯然，multiply()電話add()內部。如果add失敗，multiply()也失敗。在一個複雜的課程中，找出爲什麼確實是一個單元測試失敗可能非常複雜。

一個單元如何測試具有依賴性的方法/對象/部件？

來源

2009-12-03 Georg Schölly

我通常只是讓他們失敗 - 類應該很簡單，足以快速發現錯誤的測試。
但是，在複雜的情況下，我們使用簡單的命名約定進行測試，以確保保持某個順序（def test_00_add,def test_01_multiply）。

再次，如果你的類變大，這將是難以管理，所以就沒有得到他們很大的:)

來源

2009-12-03 07:37:23 abyx

一般來說，如果一個類是足夠複雜，這使得難以進行單元測試它，那麼你可能應該把它分成更簡單的相關類。

此外，爲了能夠使用mocks進行單元測試，在接口上而不是在具體類中設計類依賴關係是一種最佳實踐。

來源

2009-12-03 07:42:04 Konamiman

multiply內部使用add的事實是multiply的實施細節。因此，不要在測試中明確考慮這些因素，並且只需編寫測試來測試add和multiply的功能。

如果您使用TDD來獲得您的代碼，您的類不應該變得如此複雜，以至於您似乎遇到的問題存在任何實際問題。

所以本質上，我同意abyx。 ;-)

來源

2009-12-03 07:44:09 peSHIr

它的種類取決於子方法/對象/無論是內部實現細節還是協作者。

如果最終結果只有一個正確的結果，並且它永遠不會改變，那麼它可能值得一起測試它們。但是，如果'內部'對象的行爲實際上是單獨的行爲，那麼最好將它粘在一個接口後面。

我不知道如果答案是明確的或不....

來源

2009-12-03 07:48:31 kyoryu

理想的測試運行將排序了這一點。

Kent Beck developed a intelligent test runner它根據故障統計和執行時間執行測試。

一個複雜的基於流分析的測試運行器可以構造測試執行的優先級，測試其他代碼依賴的測試功能。

來源

2009-12-03 08:17:57

如何構造具有依賴關係的單元測試？

回答

相關問題