敏捷從業人員談論測試驅動開發 （TDD），所以許多關心代碼質量和可操作性的開發人員也是如此。 我曾幾何時，不久前設法閱讀了有關TDD的文章。 據我了解，TDD的關鍵是：

1. 編寫測試，但失敗
2. 代碼，使測試成功
3. 自動化測試
4. 重構代碼以提高質量
5. 重復

很容易理解。 惱火的開發人員大喊：“開發人員在編寫測試嗎？ 您如何期望我們開發和測試并及時完成功能？”。 畢竟，所有開發人員都不想做無聊的測試工作。 我從事開發人員大約兩年了，在最初的幾天里，有時我會做出這種反應。 但是隨著時間的流逝，我已經開始理解軟件開發的癥結所在。 這次我想到嘗試TDD。

我的工作涉及使用Java EE Web框架通過UI在db中連接數據庫中的數據，這是典型的Web應用程序工作。

讓我解釋一下在采用TDD之前的測試策略：

1. 編寫完整的代碼，其中包括-PLSQL過程，調用PLSQL過程的Java代碼，用于UI綁定的Java代碼以及JSP頁面本身。
2. 手動測試db層和UI層代碼的功能。 它涉及導航到頁面，然后測試各種操作。 在這種情況下，UI問題和后端代碼問題都會出現。
3. 正如我將進一步研究UI一樣，我將在代碼中發現一些錯誤，否則將編寫一個硒測試以自動測試一些用例。

通過上述3個步驟，我花了很多時間-

1. 等待后端代碼編譯，然后重新啟動服務器以使UI反映更改。 即使它只是一個簡單的1詞/ 1語句更改，我也不得不等待大約5分鐘，有時甚至是8分鐘。 當我等待重新啟動時，我會失去對其他任務的關注，因此需要一段時間才能回到主要任務。
2. 嘗試調試并找出異常/錯誤是由于UI代碼問題還是后端代碼問題引起的。
3. 等待頁面加載并瀏覽頁面到正確的頁面。

好的，那是史前時代。 現在正走向現代。 我以為我無法完成TDD的工作，這是因為我編寫了后端和UI代碼耦合不良的代碼。 我想不出一種方法來獨立測試后端代碼，然后移至UI代碼，然后通過硒測試對其進行測試。 拋開這些概念，我試了一下。 我知道我與實際的TDD距離不太遠，但感覺有點接近。

1. 我對如何實現邏輯，創建基本實現并使其成功編譯有一個很明確的想法。
2. 創建了一些數據填充測試，以獲取用于測試的數據類型。
3. 創建了JUnits以測試基本功能。 主要是通過Java API正確執行PLSQL過程。
4. 更新了JUnits以添加更多測試以測試所需的實際功能，并更新了代碼以實現這些功能。
5. 重構代碼以消除難聞的氣味，然后運行JUnits以確保沒有任何損壞。

我感到興奮的原因，以及我認為這是雙贏的策略：

• 我開始考慮的是API用戶而不是API創建者。 這使我無法添加可以解決問題但難以測試的黑客。 與以前編寫的代碼相比，這極大??地改善了代碼結構。
• 無需重新啟動服務器，每次重新啟動不會浪費?8分鐘，也不會浪費瀏覽頁面的時間。 我只需要編輯代碼，運行Junit并查看測試即可確定命運。 這對于我編寫的后端代碼更有用。
• 我專注于代碼測試周期，因此不會失去重點。
• 我看到測試顯示綠色的成就感。
• 創建具有良好單元測試的代碼以測試后端功能的可能性，這也有助于更輕松地重構代碼。

現在，我只需要為UI和后端編寫粘合代碼，并通過硒測試來測試粘合代碼。

任何人開始使用TDD時都有類似的經歷嗎？

參考： 我在測試驅動開發中的第一步-我們的JCG合作伙伴 Mohamed Sanaulla在“ 體驗無限”博客上提出的雙贏策略 。