如何在做BDD時重構和發現依賴關係

Question

做BDD意味着從上到下，所以我們首先編寫測試頂級特性。現在設置一個測試，你通常需要設置一些模擬而不是真正的節奏。你如何知道需要什麼樣的服務，你需要什麼樣的服務？我無法彌補如何定義這個級別的依賴關係。在經典的TDD中，它就像將現有的impl重構爲依賴對象一樣簡單。

BDD和嘲笑是否意味着我們需要完整的依賴關係圖組成，並大致設計了前沿？

那麼重構呢？看起來已經沒有地方可以將你的impl打破成爲依賴關係了，因爲你已經有了這些定義。

例如我有一個定時緩存功能來實現。 我的測試應該是：通過存儲調用

• 返回值如果要是緩存通過存儲調用
• 返回值，如果超時超過

它不會被緩存

返回值沒有存儲調用是否意味着我需要確定所有潛在的依賴關係並進行模擬？我應該驗證從我的xall返回的值，還是隻需要依賴關係調用？

Answer 1

我有一種感覺，你可能會過度思考這一點。當事情看起來很混亂時，我通常會提醒自己退後一步並回顧一下基本知識。首先，我只想做滿足要求的最低要求。我並不關心繫統中是否會有很多依賴項，但我還沒有意識到，所以我會以最簡單的方式編寫測試。如果我看到需要依賴關係，我會投入模擬並支持允許我的測試運行所需的最小界面。如果系統稍後需要擴展或支持附加依賴項，我可以擴展該模擬，甚至可以用我編寫的下一個測試特有的某些內容替換它。我也可以擴展測試，甚至寫一個新的測試來滿足新的需求，因爲他們對我而言是已知和/或清楚的。

重構只是一個奇特的說法，我打算改變一些東西。這可能是爲了優化或改進設計，也可能是因爲我認爲需要突破新的接口和依賴關係。在那種情況下，我首先寫一個更改到我的測試中，或者寫一個新的測試，它可能會或可能不會取代現有的測試。完成後，我會轉到我的代碼。

自上而下或自下而上，基本面基本相同。問題在於何時依賴將變得不言自明，然後確定處理它們的策略。當你覺得有必要打破某些東西時，我會建議一個很短的時間。讓這個想法成形，並在提出問題的同時將其展現在眼前。如果追求這個想法是正確的，那就寫測試來處理你的問題，然後從那裏編碼。

我有時會發現自己渴望創造一大堆嘲笑來處理我所能想到的每一種可能的依賴性意外事件，並且每當我回到重複「KISS」，「YAGNI」和「Make它會工作，然後讓它更好地工作「，一直到我的腦海中，直到我收到消息，說我無法承受，因爲我試圖思考太多。

無論您是TDD，BDD還是使用任何其他方法，保持簡單而簡單的事情都是確保您不會一次處理太多問題的關鍵。這可能是要記住的最重要的事情。如果看起來太難以想象，那麼問問自己，如果你有「需要的氣味」，這表明你需要進一步細分。你能把這個「故事」分解成一系列涵蓋整體的小故事嗎？

我知道我沒有必要直接回答你問的問題，但是我認爲這是值得用這種方式編寫的，因爲根據我的經驗，當任務很小時，依賴關係和重構就變得不言自明，並且僅限於只有一個或兩個特徵，而當任務過於廣泛並且可以解釋時則會出現相反的情況。

Answer 2

不要驅動設計與頂級（集成？） - 測試。

使用它們來知道您的功能何時完成，並使用標準的TDD實踐驅動代碼的內部。

有點短，但我希望你明白我的意思。

Answer 3

使用BDD，您不是在單位級別工作（即一個公共班級的一種公共方法）。您正在系統級別工作。因此，您需要模擬系統邊界外的所有內容。這意味着，存儲系統或外部系統將被嘲笑：文件，數據庫，服務等

此外，你會想，以確保您的規格證明自己反覆，所以像TDD，你會想戲弄取出任何非確定性因素。這意味着特別是時鐘和隨機函數，但也可能意味着天氣服務（這當然與您想要模擬的無關元素重疊）或類似的東西。

至於如何發現它們，我看到了兩種可能性，你可以使用這兩種可能性。首先是繪製一個系統圖，該圖基本上是一個代表您在SUT中的所有內容的框。然後繪製任何你知道你需要的東西，並將其歸入上述類別之一。這就是你需要嘲笑的。

另一種技術是將代碼，直到落在必須嘲笑存在依賴關係，然後與Bridge Pattern重構，以便不依賴於它。

希望這會有所幫助。