如何在你的組織中成功推廣TDD？在這篇博客中：最大限度地提高采用TDD的好處的提示，以及對TDD采用的光譜的探索，從純粹的到TDD式的。

測試驅動開發(TDD)是關于編寫精簡和吝嗇的代碼，并具有高水平的測試覆蓋率。開發人員在寫代碼之前，先針對需求寫出測試，只要測試通過，代碼就被認為是完成了。聽起來很不錯，但是如何在你的組織中成功地推出TDD呢？我們將在這里探討這個問題，其中會有一些提示，讓你最大限度地發揮采用TDD的好處。

為什么選擇TDD？

TDD的主要好處是幫助開發人員創建可維護和可測試的代碼。TDD還可以通過確保創建實現功能所需的最低限度的代碼來防止功能爬升和代碼的 "鍍金"。驗證正在編寫的代碼是否正確，也使團隊更加高效，避免將寶貴的開發資源浪費在構建錯誤的功能上。

遵循TDD在組織內部強制執行單元測試作為一種實踐。但這不是為了單元測試而單元測試。它是一種確保你正在創建可測試代碼的方法，幫助你降低維護成本并保持技術債務的低水平。通過確保你有一個堅實的回歸套件，當一些東西因代碼更改而中斷時，你會立即得到通知。

對TDD的興趣越來越大的一個重要原因是，許多組織正在向敏捷開發實踐過渡，并意識到他們現有的測試實踐過于依賴周期末的手動測試。端到端測試實踐當然有一席之地，但為了以保持競爭力所需的速度擴展開發創新，組織必須將測試工作左移。TDD是一個過程，它完全可以保證你在開發項目開始時有一個健康的測試基礎，以確保整個開發生命周期的軟件質量。

TDD頻譜

就實際目的而言，很少有人開發軟件時遵循TDD的純粹愿景，原因有幾個。現代軟件開發通常涉及整合庫、連接遺留代碼和擴展現有功能。很多人并不奢望編寫全新的代碼，所以純TDD在很多情況下并不實用。相反，許多 "做TDD "的人坐在類似這樣的光譜上。

雖然每個組織在TDD方面都有自己的一套具體挑戰，但從客戶那里聽到最多的問題符合上述三種基本類型。但在這個范圍內，TDD從業者有很多類型。

TDD Ninjas

在光譜的一端，是那些成功實踐TDD的 "黑帶 "級別的人。這些人完全致力于TDD原則，在寫測試之前不寫任何東西--沒有骨架，沒有定義，沒有任何東西--只要測試通過就結束了。因此，代碼效率高，可維護性強。當人們與TDD Ninjas交談時，他們經常承認，他們在組織內部各團隊實施TDD的成功率是不均衡的。

TDD實用主義者

接下來的人可能會設計類、方法簽名等，然后針對這些定義編寫測試。在API層面，這相當于編寫OpenAPI/Swagger或WSDL定義。我們稱之為TDD的實用主義方法。

這種方法更容易采用，因為它提供了更多的結構和更清晰的內容。所有的東西都是編譯的，這樣一個小隊就可以更容易地一起工作。然而，潛在的權衡是，TDD實用主義者可能并不總是能實現TDD忍者所實現的高效率、最小化的代碼設計。

傳統的TDD

有很多人很想完全投入到TDD中去，但又不舍得從綠地代碼開始。這些人經常創建測試來重現缺陷，或者測試預期的行為，以便基于遺留代碼改變或擴展現有功能。

在那些自認為是TDD實踐者的人中，有很大一部分人處于或接近這個譜系中的這一點。其邏輯是，雖然測試和代碼是密不可分的，但測試并不一定先于代碼。然而，測試確實先于代碼的修改。

TDD式

TDD的另一端，是測試和代碼并行的人。對于TDD式的從業者來說，只要測試和代碼一起投入和管理，就認為開發是由測試驅動的。

實施測試驅動開發（TDD）的4個技巧

那么如何成功采用TDD呢？按照下面的四個技巧來實現TDD的成功。

• 將TDD應用于遺留代碼

當一個組織繼承了不可測試的代碼，而它又沒有能力償還技術債務時，一個常見的TDD實現問題再次出現。是否應該對代碼進行重構？如果是的話，需要多少重構才能以有意義的、可實現的方式開始實踐TDD？

如果有任務開始在遺留代碼上做TDD，那么試圖實現理想的TDD是行不通的。你所繼承的代碼并沒有考慮到可測試性，原作者可能已經不在團隊甚至不在組織中，依賴的庫可能已經發生了變化，等等。

所以，如果遺留代碼已經在那里工作了，相對于新的未經測試的工作的風險，技術債務帶來的風險是很低的。通過將TDD應用于你正在編寫的新代碼，即對現有代碼的修改，你可以將風險降到最低，并且不會增加技術債務。

為了克服測試現有代碼的挑戰，您可以使用Parasoft Jtest的單元測試功能來快速創建有意義的測試。Parasoft Jtest可以分析遺留代碼及其依賴關系，減少創建JUnit測試用例和實現現有代碼所需的復雜存根/對接的時間。

• 將TDD應用于微服務

基于微服務的架構比傳統的應用堆棧具有更多的依賴性和復雜性，將更多的不穩定性引入到測試環境中。由于需要先進的嘲諷和存根，為基于微服務和其他復雜架構的應用程序創建測試可能是困難的。

然而，基于微服務的架構提供了以非常有效的方式利用TDD最佳實踐的機會。如果你把微服務視為單元，而不是編譯單元，那么TDD實用主義方法就會變得非常有用。

當在API層面應用TDD時，你的API是在合同（OpenAPI/Swagger，WSDL）中定義的。API測試解決方案，如Parasoft SOAtest，就可以根據這些定義自動創建測試。然后只需要準備好根據定義開發功能，直到SOAtest測試通過。

• 啟用小隊

TDD通常被視為以開發人員為中心的活動，通常通過在單元測試框架（如JUnit或NUnit）中創建測試來封裝。然而，大多數組織根本沒有足夠的開發人員或時間來覆蓋所有的用例。這對于那些對其項目有多種角色和技能貢獻的企業組織來說，尤其是一個問題。

如上文所述，在API層面利用TDD實踐來處理微服務，可以幫助您解決技術資源有限的問題，使您能夠利用測試人員的專業知識來根據合同定義測試。通過這種方法，業務分析師、測試人員和其他非開發人員資源能夠為TDD測試工作做出貢獻。

您也可以使用服務虛擬化解決方案，如Parasoft Virtualize，來立即創建模擬功能，您可以在編寫任何代碼之前，針對這些功能構建和執行測試。

• 用 "局域分工 "加強時效性

實現TDD有幾個好處，但TDD本身并不一定能轉化為符合需求的代碼。它只是確保代碼被測試所覆蓋，并且測試通過。這就是行為驅動開發（BDD）的作用。開發者不是在測試通過之前寫代碼，而是在行為實現之前寫代碼。

值得指出的是，過去曾有人試圖在編寫代碼之前定義功能框架。有誰還記得按合同設計（DbC）嗎？事實上，BDD是實現這種方法的最新嘗試。在BDD（或DbC）中，在創建測試或代碼之前，必須先定義前和后條件。BDD代表著將TDD提升到一個新的水平的機會。如果你使用的是BDD語言，如Gherkin，你可以擴展自動化測試。而Parasoft SOAtest(用于API測試)和Parasoft Selenic(用于Selenium驅動的UI測試)可以降低編寫必要的膠合代碼和步驟定義的技術復雜性，而這通常需要開發人員資源。

結論

測試驅動開發的承諾是基于精益開發理念的。它旨在幫助你生成高效、可測試、可維護的代碼。但現實世界的條件并不總是讓TDD的采用變得容易。 可以幫助您以一種對您的組織來說實用的方式采用 TDD 實踐，使您能夠最大限度地利用您的開發/測試資源。聯系在線客服，了解如何幫助您在組織中實施TDD的詳情。