在TDD中處理實現問題

我剛剛開始使用TDD，很快就遇到了一堵磚牆。這裏是我的情況... 我試圖模擬一個Image對象，並通過我已經開始與一個簡單的對象，最終成長爲TDD步驟去......在TDD中處理實現問題

public class ImageObject 
{ 
public string Name {get; set;} 
public int Width {get; set;} 
public int Height {get; set;} 

public bool IsValid() 
{ 
    //Some rules 
} 
}

當然義不容辭測試...

[Test] 
public void ImageWidthCannotBeLessThanZero {...} 
[Test] 
public void ImageHeightCannotBeLessThanZero {...}  
and so forth...

到目前爲止好。接下來，我想以某種方式表示類中的物理文件。這可能是一個文件路徑

public class ImageObject 
{ 
    public string Path {get; set;} 
}

或一系列字節

public class ImageObject 
{ 
    public byte[] Bytes {get; set;} 
}

的（請這不是關於數據庫的參數，相較於存儲文件系統）。

在這一點上我我感覺不舒服，因爲我的思想正在漂移，並開始考慮基礎設施/實施細節。我的缺陷在哪裏？我應該在實施細節上做出決定嗎？我是否需要一個聰明的設計模式來處理這個問題？模擬框架會有幫助嗎？這是一個對象分析/設計問題，我應該使用UML工具？（等一下我以爲TDD是關於設計的？）

無論如何，我如何克服這個問題？我想繼續專注於設計我的對象，而不是現在考慮基礎設施問題？

來源

2010-10-27 Fixer

我認爲你可能會從錯誤的地方開始。你說'接下來，我想以某種方式代表班級中的物理文件' - 爲什麼？哪些測試失敗導致需要表示物理文件？

一個問題是，你通過公共屬性公開表示 - 這真的是你想要做的嗎？或者可以將物理表示保持爲私有狀態，只能通過您選擇實現的某些操作（例如'LoadImage（）'，'GetImageBytes（）'）進行訪問？如果它是保密的，那麼對於你的測試來說，實現是什麼並不重要。

來源

2010-10-27 10:29:41

你是說我現在不應該擔心物理文件嗎？而當我開始設計ImageObject的使用者時，我應該擔心這一點？ – Fixer 2010-10-27 10:35:25

現在你可以開始思考這個問題了，我只是用TDD來說，根據行爲來做。就像在我的例子中，如果你需要獲取圖像的字節，你可能有一個GetBytes（）方法，而不是直接訪問物理表示。然後你可以爲GetBytes（）編寫測試，然後實現它，但是你需要物理上的。在這個發展階段，你可能會也可能不會關心。 – 2010-10-27 10:44:22

@Fixer - 單元測試是'ImageObject'的消費者 – Gutzofter 2010-11-02 15:28:21

在TDD中，正在開發的類應該從外部的角度考慮。圖像來自哪裏？你打算如何處理圖像？顯示它？通過網絡發送它？對它應用一些轉換？插入畫廊？答案將會提供方向。接下來的測試寫。測試將指導設計，而不是Image類可能是什麼。

事實上，對於繪圖應用程序，畫廊發生器或電子郵件閱讀器，該ImageObject將是不同的，因爲這將使用這個類的類有不同的需求。

來源

2010-10-27 11:35:29 philant

您過於關注建模該類，而不是實現實際的場景。

恕我直言，這是在當你使用TDD如何解決這些問題有很大的區別。

這是什麼讓你增加了班不必要的元素，使你走向以較少的前期分析時更簡單的設計去。

專注於你需要實現的方案。讓它驅動你對這些課程的需求以及你需要的內容。

來源

2010-10-27 17:44:06 eglasius

在TDD中處理實現問題

回答

相關問題