單元測試。在創建界面之前還是之後？

Question

在我最近的項目中，我和我的團隊成員聚集在一起，完成了需求，並創建了我們都同意的接口（包含方法聲明，但不包括實現）。然後，我們開始編寫單元測試，然後執行。

現在，我的項目負責人說我們的方法是錯誤的。他在說我們應該先創建一個測試，然後提出接口。

我們首先想到接口的原因之一是因爲我們認爲我們必須有一個接口聲明才能創建模擬測試。

哪一個是正確的方法？

Answer 1

測試驅動開發以單元測試開始。

在你的單元測試中，你定義了樹的階段：Arrange，Act和Assert。此時你的代碼將不會編譯，因爲類/接口尚未定義。

但是這個步驟的確幫助你考慮你的接口。在你的情況下，你可以編寫一套單元測試來描述你需要的類和接口，而不是在白板上討論你需要的接口和方法。

通過以測試優先的方式編寫單元測試，您在考慮實現之前強制自己查看類的外部。這是做TDD的方法。

在爲您的項目定義所有接口時需要考慮嘲笑。在你的單元測試中，你測試一個班級。一個具體的對象。在寫這個對象時，你會遇到你的課需要其他對象的情況。這就是您開始思考導致使用接口和依賴注入的依賴關係的時刻。

Answer 2

應用TDD時，您首先從測試開始......您首先要寫下描述業務邏輯的測試用例。沿着這些測試，必要的接口/方法變得明顯..我認爲編寫第一個接口或測試用例並不重要。更重要的是在這兩個步驟之後編寫接口的實現！

Answer 3

比TDD

開始上述TDD更多，想故事的字詞或使用的情況下，他們有要求。根據測試定義要求。假設您正在銷售襪子的網站上工作。這個故事可能是這樣的：作爲一個客戶，我需要輸入我要購買的物品的數量，這樣我才能獲得套餐折扣。因此，您創建了一個測試，說「客戶輸入了24雙襪子，確保訂單中添加了5％的折扣。」但這真的很高。你看代碼並說：「嘿，我甚至不支持數量。」因此，您可以考慮訂單上的訂單項以及他們需要購買數量的方式。您爲您的LineItem對象編寫一個測試，其中說明了

LineItemTest::testAddQuantity() 
{ 
    LineItem lineItem = new LineItem(); 
    Item item = new Item(); 
    lineItem.add(item); 
    lineItem.addQuantity(7); 
    ASSERT(lineItem.getQuantity() == 7); 
} 

並且您實現了該代碼。您現在認爲數量更難，並且爲負數量，超出最大數量等數量添加了更多測試。然後，您會發現訂單項的價格受到數量的影響。您的商品已有價格，但價格並未按數量延伸。所以你添加一個，因爲你需要一個。

LineItemTest::testExtendPrice() 
{ 
    LineItem lineItem = new LineItem(); 
    Currency price = 1.00; 
    Item item = new Item(price); 
    lineItem.add(item); 
    lineItem.addQuantity(7); 
    ASSERT(lineItem.getExtendedPrice() == 7.00); 
} 

所以我們通過定義一個新的需求來改變LineItem上的接口。

最重要的一個教訓是，如果我們在設計LineItem接口時沒有想到ExtendedPrice，我們就會陷入這裏，因爲我們的需求迫切需要一個接口。使用TDD，您不必事先設計它，因爲無論您在設計過程中有何想法，無論如何，您最終都會需要它。

緊急設計

這種方法被稱爲緊急設計的，這也是爲什麼TDD通常被稱爲設計方法，不是測試方法。您不要提前花大量時間，思考所有的設計元素，以及所有界面是什麼，他們究竟做了什麼，以及如果我們需要批量折扣，該怎麼辦？ 。這是一種大型設計預先方法，導致遺漏錯誤。另一個例子可能是你忘記檢查折扣的銷售稅，如果他們使用優惠券等。相反，只有當您需要制定這些決策時，纔會將這些決策推遲 - 當您正在處理需求時。

緊急設計是實現結果的不同途徑。它讓你隨時思考，而不是事先考慮，它可以讓你對手頭的事實做出正確的反應，而不是試圖想象所有的事情。它在現階段充分利用軟件的靈活性和可變性。

此時，您還允許輸入所有「假設」。如果輸入負數，該怎麼辦？添加另一個測試！

節省時間

在敏捷的世界裏，這種做法有另一大優勢：如果您的客戶決定推遲，取而代之的是更重要的特徵的特徵，你沒有浪費時間設計它。客戶通常以不同的方式排列優先順序。我聽到這樣的決定很多：「折扣今天並不重要，我不會在明年之前開展這些促銷活動，現在，我真的需要你們實現銷售稅一體化。」

單元測試可以實現這種靈活性。通過單元測試，您可以更改任何內容並免費重新運行測試，相信您的更改不會造成任何其他問題。

問題避免

一個大設計了前面不保護你。相反，它會阻礙你在正確的時間做正確的事情。我看到團隊被一個完全忘記了一些細節的大設計所困住，而不是固定設計來增加細節，而是彌補了缺陷。 「我的項目進度落後，我們現在無法改變設計，我們只會做一個解決方法。」這就是真正的意大利麪代碼來自哪裏，而且這通常是過程導致糟糕決策的錯誤。

外部依賴

通常情況下，儘管你在網絡內部創建的內容，你仍在處理與外部世界。服務，固定需求，傳統數據庫模式，所有這些都是您必須在TDD中處理的真實世界問題。所以如果你有另一個系統的外部接口，你如何接近它？正如你會有其他要求：進行測試。

這主要是你的嘲笑會發揮作用的地方。您將創建一個模擬服務，實現現有的Shipping界面。您將使用TDD編寫代碼以與該界面進行交互。你可能發現在它周圍編寫一個薄包裝器是有利的，然後在你的代碼中訪問適配器 - 它可以讓你編寫一個模擬包裝器，而不是編寫一個完整的模擬服務。