許多書上都討論了自動測試，但是只有很少的著作注意到這么一個問題，那就是怎樣把這些測試組織起來。隨著測試的增加，放置和調用這些測試卻變得更加麻煩。這將成為一個重要問題，以至于出現了TDD，極限編程（XP）使TDD得以普及。另外，你可以這樣理解TDD：通過測試來開發。
TDD的主要規范：
在編寫程序代碼之前，與之對應的自動測試必須被寫好。甚至程序代碼并不存在，那也要看見一個失敗的測試結果。
在測試通過后，副本代碼必須被丟棄。
有一個具體步驟（可能指的是《Extreme Programming》）可以被任何一個程序員來參考，而不需要特殊的其他方法。在我們開始寫測試之前，這些步驟（章節）應該被首先閱讀——怎樣組織自動測試。
講解一下不同種類的測試：
單元測試：檢測模塊（也就是類）的正確性。如果對象需要訪問外部的數據資源，例如數據庫，就需要模擬一個mock objects，但在實際中真實數據與測試環境是不同的。
客戶測試：這是功能性、系統、和驗收測試。用來測試整體的系統特性。在XP中，這些測試由用戶編寫。
綜合測試：介于用戶測試和單元測試之間的橋梁。綜合測試幫助測試應用程序的交互性。一般情況下，mock objects不被用于綜合測試，它會增加測試時間。同樣，綜合測試經常依賴特殊的測試環境，例如數據庫送來的測試數據。綜合測試也需要用到外部類庫。例如為J2EE應用程序進行綜合測試的類庫Cactus。解釋這些測試超出了本文的范圍，需要更加詳細的信息請參考http://jakarta.apache.org/cactus/。
開發人員測試：這是用來讓開發人員檢驗自己代碼或新函數的。對于每一個開發人員，只要有可能，就需要有更多的測試來檢驗代碼。組織這些測試和組織程序代碼一樣重要。
在以下章節，只要提到“測試”，那就指的是開發人員測試。
我們幾乎準備好開始建立測試了，先應該為我們的測試選擇名字。你也許會說，“這不是問題：把‘Test’這個字放在類名前面，就好了！”不會這么快！讓我來說一下這個步驟存在的問題：
文章來源于領測軟件測試網 http://www.kjueaiud.com/