測試驅動開發 測試前移

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

編寫測試，但失敗

代碼，使測試成功

自動化測試

重構代碼以提高質量

重復

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

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

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

編寫完整的代碼，包括-PLSQL過程，調用PLSQL過程的Java代碼，用于UI綁定的Java代碼以及JSP頁面本身。

手動測試db層和UI層代碼的功能。 它涉及導航到頁面，然后測試各種操作。 在這種情況下，UI問題和后端代碼問題都會出現。

正如我將進一步研究UI一樣，我將在代碼中發現一些bug，否則編寫一個selenium測試以自動測試一些用例。

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

等待后端代碼編譯，然后重新啟動服務器以使UI反映更改。 即使它只是一個簡單的1詞/ 1語句更改，我也不得不等待大約5分鐘，有時甚至是8分鐘。 當我等待重新啟動時，我會失去對其他任務的關注，因此需要一段時間才能回到主要任務。

嘗試調試并找出異常/錯誤是由于UI代碼問題還是后端代碼問題引起的。

等待頁面加載并瀏覽頁面到正確的頁面。

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

我對如何實現邏輯，創建基本實現并使其成功編譯有一個很明確的想法。

創建了一些數據填充測試，以獲取用于測試的數據類型。

創建了JUnits以測試基本功能。 主要是通過Java API正確執行PLSQL過程。

更新了JUnits以添加更多測試以測試所需的實際功能，并更新了代碼以實現這些功能。

重構代碼以消除難聞的氣味，然后運行JUnits以確保沒有任何損壞。

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

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

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

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

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

翻譯自: https://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html

測試驅動開發 測試前移

總結

以上是生活随笔為你收集整理的测试驱动开发 测试前移_测试驱动开发–双赢策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。