我有一個「配方」方法,我試圖用TDD編寫。它基本上召喚出不同的方法,有時使得基於這些方法的結果決定:單元測試理念
public void HandleNewData(Data data)
{
var existingDataStore = dataProvider.Find(data.ID);
if (data == null)
return;
UpdateDataStore(existingDataStore, data, CurrentDateTime);
NotifyReceivedData(data);
if (!dataValidator.Validate(data))
return;
//... more operations similar to above
}
我的本能反應是,我確認HandleNewData調用上面傳遞的預期參數見過的方法來啓動編寫測試用例並且在方法調用失敗的情況下返回。 但是這種感覺對我來說就像是一次巨大的投資,用來編寫這樣一個測試,幾乎沒有實際的好處。
那麼寫這樣一個測試的真正好處是什麼?還是真的不值得這麼麻煩?
它似乎只是代碼本身的一個超規範,並且只要代碼需要調用另一個方法或決定不再調用當前方法之一,就會導致維護問題。
我應該澄清,我正在做的是重構一些舊的遺留代碼。我的願望是讓它看起來像上面這個簡單的例子,我試圖用TDD來實現上面的實現 – dmg 2011-05-23 22:46:51
我認爲Johnsyweb的觀點是測試驅動設計首先不會達到上述實現,你有很好的理由難以測試,這是一個警告信號,表明這是一個糟糕的設計。 你當然可以在測試中包裝這個實現,但是如果你的測試沒有綁定到當前的實現上,你也可能想要考慮你的測試會是什麼樣子。如果你要開始一個高層次並深入研究行爲,這個方法將實現你將要寫什麼測試,什麼組件,你能在這裏使用這個結構嗎? – Jonah 2011-05-24 00:10:20