TDD：添加一種方法來測試狀態

Question

因此，我開始爲一個簡單的程序（側面玩具遊戲）編寫一些邏輯。你有一個特定的船舶（稱爲設置），它是一個船+模塊。您從基於船舶的空設置開始，然後將模塊添加到該設置。船舶也有編號陣列的模塊位置。

var setup = new Setup(ship); // ship is a stub (IShip) defined someplace else 
var module = new Mock<IModule>().Object; 
setup.AddModule(module, 1); // 1 = which position 

所以，這是我測試方法中的代碼。我現在需要在此代碼上聲明。那麼，我需要一個getter方法嗎？

Assert.AreEqual(module, setup.GetModule(1)); 

這聽起來很愚蠢，我擔心什麼，但對於一些愚蠢的原因，我關心的是添加一個方法只是斷言，測試通過。

這樣好嗎？其實是TDD推動的設計過程的一部分？例如我知道我需要一個AddModule方法，因爲我想測試它，而這需要一個GetModule方法來測試，這只是我的設計通過TDD進化而來的。

或者是這種氣味，因爲我甚至不知道我是否真的需要GetModule在我的代碼中，它只會用於測試？

例如，添加模塊將最終影響裝備的不同屬性（護甲，盾牌，火力等）。事情是那些將變得複雜，我想從一個簡單的測試開始。但最終，這些都是我關心的公共屬性 - 設置由其統計數據定義，而不是由模塊列表定義。

Answer 1

有趣的問題。我很高興聽到你先寫測試。

如果您讓設計通過測試來體現自己，那麼您更可能僅構建需要的部分。但這是最好的設計嗎？也許不是，但不要讓這讓你灰心 - 你的添加方法起作用！

如果您稍後需要GetModule方法，可能爲時尚早。現在，建立你需要的功能並開始綠色，然後慢慢地重構它（再次從紅色變成綠色）以獲得你想要的設計。

Answer 2

我會警惕在我的課堂中引入一個只用於測試的公共方法。

有很多種方法，你如何能測試：

反思：該GetModule方法是在你的類的私有方法（這也可以，如果你的「統計」是私人的工作），你可以訪問它在你的測試方法中通過反射。如果你改變私有方法的名稱或者添加/刪除一些變量（但是，當然，你的測試將會失敗並且你會提前知道），這將會很好地工作，唯一的麻煩是你不會得到任何編譯器錯誤

繼承：GetModule方法可以被保護（只有繼承是可見的），並且你的測試類可以繼承自主類。這樣你的測試類就可以訪問這個方法，但這並不真正暴露給外部世界。

斷言副作用：這是您真正考慮將模塊添加到系統意味着什麼的地方。如果它會影響某些「統計信息」，則可以編寫測試來確定統計信息已經過適當修改。

Answer 3

進化設計的一部分是開始像一個簡單的方法，嬰兒的步驟，然後發展成複雜的統計數據（最終下探此方法，並更改測試）時，足夠支持它。在進行TDD時，不要指望你寫的第一個測試是針對理想的界面。隨着設計的發展，可能會出現一些混亂現象。

話雖這麼說，如果你看到沒有公共目的的方法，嘗試儘可能多的限制了它的知名度是合理的測試代碼。雖然甚至應該最終會消失當你打造出來的系統的其餘部分，有一些真正的測試爲set方法的副作用。