2009-09-02 109 views
21

我有一個名爲TestMakeAValidCall()的單元測試。它測試我的手機應用程序進行有效的通話。單元測試 - 是否有單元測試調用其他單元測試的不良形式

我即將編寫另一個測試,名爲TestShowCallMessage(),需要有一個有效的測試呼叫。在該測試中打電話給TestMakeAValidCall()是不是很糟糕?

供參考這是我的TestMakeAValidCall()測試。

[TestMethod] 
    public void TestMakeAValidCall() 
    { 
     //Arrange 
     phone.InCall = false; 
     phone.CurrentNumber = ""; 
     // Stub the call to the database 
     data.Expect(x => x.GetWhiteListData()). 
      Return(FillTestObjects.GetSingleEntryWhiteList()); 
     // Get some bogus data 
     string phoneNumber = FillTestObjects.GetSingleEntryWhiteList(). 
      First().PhoneNumber; 
     // Stub th call to MakeCall() so that it looks as if a call was made. 
     phone.Expect(x => x.MakeCall(phoneNumber)). 
      WhenCalled(invocation => 
         { 
          phone.CurrentNumber = phoneNumber; 
          phone.InCall = true; 
         }); 

     //Act 
     // Select the phone number 
     deviceControlForm.SelectedNumber = phoneNumber; 
     // Press the call button to make a call. 
     deviceMediator.CallButtonPressed(); 

     //Assert 
     Assert.IsTrue(phone.InCall); 
     Assert.IsTrue(phone.CurrentNumber == phoneNumber); 
    } 
+0

感謝所有的好的答案。我將重複代碼重構爲單獨的調用。我以最多的選票選出答案。 – Vaccano 2009-09-02 17:17:19

回答

51

將設置重構爲另一個方法並從兩個測試中調用該方法。測試不應該調用其他測試。

+3

不要用測試測試另一個測試 – 2013-02-11 11:05:00

+0

在這種情況下,有人可以精心研究重構的樣子嗎? – 2015-11-28 15:33:25

+1

@Nakata - 很難在不知道依賴關係是如何構造的情況下顯示這個示例的確切代碼,但是這個要點顯示了我用來將代碼設置在測試環境中並在多個測試中從那裏調用它的模式。 https://gist.github.com/tvanfosson/1ca6dd3bb0b796de65b0 – tvanfosson 2015-11-28 16:10:41

6

我認爲它是一個壞主意。你希望你的單元測試只測試一件事情和一件事情。不要通過其他測試創建一個呼叫,而應該嘲笑一個呼叫並將其作爲參數傳遞。

11

恕我直言,你應該做下列之一:

  • 創建一個返回的有效調用的方法,並分別用其來進行測試(而不是一個調用其它)
  • 模擬的有效通話ShowCallMessageTest
4

單元測試應根據定義測試代碼的一個單元/函數。調用其他單元測試使其測試多個單元。我把它分解成單獨的測試。

2

是的 - 單元測試應該是分開的,應該只測試一件事情(或者至少少數幾件緊密相關的事情)。順便說一句,在您的測試方法的調用data.Expect和phone.Expect創建的預期,而不是存根調用,它可以使你的測試脆弱,如果你重構......

+0

感謝您對我的術語進行更正。我已經更新了我的源代碼中的評論。 – Vaccano 2009-09-02 17:18:16

6

提供了一個反襯點:

我堅信精心設計的單元測試應該是互相依賴!

當然,只有當測試框架知道這些依賴關係時,纔有意義,這樣當依賴關係失敗時,它可以停止運行依賴測試。更好的是,這樣的框架可以將測試夾具從測試傳遞到測試,這樣就可以建立在不斷增長和擴展的夾具上,而不是從頭開始重新構建每一個測試。當然,緩存完成時要注意,如果多個測試取決於同一個示例,則不會引入副作用。

我們在JExample extension for JUnit中實現了這個想法。目前還沒有C#端口,但有端口RubySmalltalk和... most recent release of PHPUnit picked up both our ideas: dependencies and fixture reuse

PS:folks are also using it for Groovy

+0

有意思的是,如果做得對,它可以減少重複很多。 – 2010-02-19 12:20:05

1

單元與模塊....我們也認爲測試也應該依賴於可重用的方法,並且應該在api級別的測試集成類中進行測試。許多人只是測試一個班,但許多錯誤是在班級之間的整合。我們也使用verifydesign來保證api不依賴於實現。這允許你在不觸及測試的情況下重構整個組件/模塊(我們經歷了一次,實際上它運行得很好)。當然,任何體系結構的變化都會迫使你重構測試,但至少模塊中的設計變更不會導致測試重構的工作(除非你改變api的行爲,當然這比隱瞞地發射更多的事件,無論如何,「將是一個API變化)。