2010-05-05 43 views
4

我有一種方法,它們有一些不同的結果(基於事件響應等)。但這是一個由其他應用程序使用的單個原子函數。用於複雜功能的TDD方法

我已經將構成此函數的功能的主要塊分解爲不同的函數,併成功地將測試驅動開發方法應用於這些元素中的每一個的功能。但這些元素不會暴露給其他應用程序使用。

所以我的問題是我該如何/應該如何輕鬆接近TDD風格的解決方案來驗證應該調用的單一方法在沒有大量測試重複或每次測試所需的大量設置的情況下都能正常運行?

我已經考慮過/考慮將功能塊移動到不同的類中,並使用Mocking來模擬所使用函數的響應,但它感覺不對,並且各個方法需要寫入主類中的變量(它真的感覺到希思羅賓遜)。代碼大致看起來像這樣(我已經刪除了很多參數以使事情更清晰,並附帶一些不相關的代碼)。

public void MethodToTest(string parameter) 
{ 
    IResponse x = null; 

    if (function1(parameter)) 
    { 

     if (!function2(parameter,out x)) 
     { 
      function3(parameter, out x); 
     } 
    } 

    // ... 
    // more bits of code here 
    // ... 

    if (x != null) 
    { 
     x.Success(); 
    } 
} 
+0

有人可能會說,如果一個方法影響應用程序中的某個部分而不提供任何類型的return/respons(如果它失敗或失敗),那麼設計會出現問題。 我會重構該方法,首先創建一個測試方法! (你可以在這裏閱讀有關它的信息:http://blog.smartit.se/2010/04/23/use-test-driven-development-to-verify-that-the-code-will-always-work/) 。如果方法返回void並且不拋出任何異常,那麼它可能工作正確?也許是Fauly的設計。但這只是一個指針而不是回答:) – 2010-05-05 18:21:27

回答

1

我想你會通過避開out關鍵字並重寫代碼使得你的生活更輕鬆,以便函數檢查響應的某些條件,或者修改響應,但不能同時修改響應。喜歡的東西:

public void MethodToTest(string parameter) 
{ 
    IResponse x = null; 

    if (function1(parameter)) 
    { 

     if (!function2Check(parameter, x)) 
     { 
      x = function2Transform(parameter, x); 
      x = function3(parameter, x); 
     } 
    } 

    // ... 
    // more bits of code here 
    // ... 

    if (x != null) 
    { 
     x.Success(); 
    } 
} 

這樣,你就可以開始拉開,更容易重新組合您的方法大的碎片,並在最後,你應該有這樣的:

public void MethodToTest(string parameter) 
{ 
    IResponse x = ResponseBuilder.BuildResponse(parameter); 

    if (x != null) 
    { 
     x.Success(); 
    } 
} 

...其中BuildResponse是你所有當前的測試所在的地方,而MethodToTest的測試現在應該相當容易地模擬ResponseBuilder。

0

恕我直言,你這裏有幾個選項:

  1. 打破內部函數進行分成不同的類,所以你可以嘲笑他們,並確認他們被稱爲。 (你已經提到過)
  2. 聽起來像你創建的其他方法是私有方法,並且這是這些方法的唯一公共接口。如果是這樣,你應該通過這個函數運行這些測試用例,並驗證結果(你說這些私有方法修改類的變量)而不是測試私有方法。如果這太痛苦,那麼我會考慮重新設計你的設計。

在我看來,這個班正試圖做不止一件事。例如,第一個函數不會返回響應,但另外兩個函數會返回。在你的描述中你說這個功能很複雜,需要很多參數。這些都是你需要重構你的設計的標誌。

0

你最好的選擇確實是模擬函數1,2,3等。如果你不能將你的函數移動到一個單獨的類,你可以看看使用嵌套類來移動函數,他們能夠訪問外部類。之後,您應該能夠使用mocks而不是嵌套類來進行測試。

更新:通過查看您的示例代碼,我認爲您可以通過查看訪問者模式和測試方法來獲得一些靈感,這可能是適當的。

0

在這種情況下,我認爲你只是嘲笑方法調用,如你所說。

通常情況下,您會先編寫測試,然後以一種方式編寫方法,以便所有測試都通過。我注意到,當你這樣做時,寫的代碼非常乾淨並且非常重要。此外,每個班級都非常好,只有一個責任可以輕鬆測試。

我不知道什麼是錯,但有些東西沒有smell正確,我認爲可能有更優雅的方式來做你正在做的事情。