在TDD之前要創建什麼設計模型？

Question

摘要：

你包括和/或在您的TD交付 - 設計VS -Development什麼模型和圖表，爲什麼？

詳情：

新型4開發項目，在一個商店，我們正在逐步地讓管理方面取得進展，從畢業「買」，在採用TDD /期望，「行動」。我是（開發人員）想要爲新項目設計測試驅動設計。管理層願意讓測試驅動開發 - 創建一些模型和圖後（這將補充UI樣機傳達詳細的設計給客戶顯著發展開始之前）。

那麼，鑑於上下文，您認爲哪些模型和圖表是合理的？這個項目的可交付成果是一個既不平凡也不過分複雜的Web應用程序。我們有一個需求文檔（有時候是模糊的，但是對於編寫測試來說是一個好的開始）。但是到目前爲止我所使用的TDD體驗（我單獨使用TDD的一個非常低缺陷項目，以及一些設計成熟的同行測試在這裏和那裏編寫）讓我想要接下來的測試驅動設計。

創建模型/圖表（看起來像我們將提供一些類模型和幾個高級用例和序列圖）的過程似乎給我們（開發人員）沒有設計洞察力，TDD不會，而且他們技術性/複雜性足以讓我擔心任何非開發人員在呈現他們時都會有效地忽略他們（讀取：盲目接受他們）。

你在哪裏畫包括和不包括模型和圖表在TD - 設計VS - 發展之間的界限？

Answer 1

軍中有句名言：「計劃什麼都不是，計劃就是一切。」如果圖表與客戶就如何設計系統設計，以及它打算包含哪些領域以及如何繼續進行有用的溝通，那麼計劃的實踐是值得的。

TDD建議的是，當橡膠符合編碼之路時，該設計可能會發生變化。問題是，當這些變化發生時，將會有多重要。但是在複雜的體系結構中，只要您意識到正在規劃，而不是固定的計劃，即使在TDD的背景下，一些前期規劃也很有價值。引導原始設計的思想是可以參考的，以瞭解TDD發現了什麼以及需要如何改變以適應它。

之後，您可以回頭向管理層指出最終產品與預先計劃有什麼不同，並查看更改的內容，也許可以指出，儘早確定設計並沒有起到作用就像他們認爲的那樣。

Answer 2

我個人不認爲我的設計文件將與TDD改變與發展的另一種模式。我會先從高層次的用例開始，然後慢慢下去，直到我有非常具體的功能用例文檔（以及所有其他隨附文檔，如類圖，活動圖等）。

一旦你擁有了這些白盒用例......你應該知道兩件事情：

1. 什麼代碼應該做的。
2. 什麼代碼不應該做。

然後，您可以編寫應用程序做的事情它應該...和你的代碼測試，以確保它不會做的事情，它不應該。

Answer 3

TDD不應該依賴於固定的模型和圖表，否則你限制或破壞其重構的過程。

所以，如果你真的需要的模型，我會使用像序列圖的一些高級別圖表來ilustrate您的應用程序的導航（其中有不到你的類圖改變的機會）。

另一點是，高層次的文物可以幫助你的客戶創造的測試程序來驗證系統的功能。

Answer 4

既然你需要生成一些文件，你想沒有人真正關心，你應該想想真的會幫助你的開發團隊：

• 在領域驅動設計模式，創造出一些顯示您的基本模型對象的文檔。盡你所能去弄清楚不清楚的概念並達成一致的術語。這兩個問題都會在開發週期中造成「浪費」，無論是否爲TDD。

• 討論項目的最大風險。是否有一些圖表，以及之前和之後的討論可以幫助減輕這些風險？

• （我做了這個）爲您的測試設計一套基本的「夾具數據」。捕獲所有重要關係和案例的最小數據集是什麼？這是一個非傳統的神器，所以你可能還沒有這個。但是這需要一段時間才能發展。一旦你擁有了它，它會加快你的測試寫作，而且它實際上可能會成爲一個有用的通信文檔的副作用。我在我們上一個項目中爲我們的夾具數據製作了一個小型海報，以便於編寫測試。