“測試驅動開發(Test-Driven Development, TDD)，以測試作為開發過程的中心，它要求在編寫任何產品代碼之前，先編寫用于定義產品代碼行為的測試，而編寫的產品代碼又要以使測試通過為目標。當我們在當前結構中找到最佳設計時，由于有足夠的測試做保障，我們可以改動現有設計而不必擔心破壞已完成的功能。使用這種開發方法，我們可以讓設計更加優良，能編寫出可測試的代碼，同時還能避免在不切實際的假設基礎上過度的設計系統。要得到這些好處，只需不斷添加可執行測試，一步步地驅動設計，從而最終實現整個系統簡單從好用。何謂測試驅動開發本文所說的TDD為單元測試驅動開發，是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。它的主要推動者是 Kent Beck。TDD的周期為“測試-編碼-重構”。測試先行，然后編碼，最后設計。這種“設計后行”的思維方式有別于傳統的“設計-編碼-測試”過程中的設計。這種事后設計的方法可稱為重構，表示把當前的設計轉化成一個更佳的設計的過程。TDD的周期也可以用“紅-綠-重構”表示。

1、先寫測試第一步，在寫測試也是在做設計。我們是在設計API，即用來訪問新功能的接口。編碼之前寫測試，我們會很自然地考慮新代碼的調用方式。注意：測試的粒度應為“正好足以失敗”。而不是一次寫出整個功能點的測試，再用一個小時寫代碼讓測試通過。2、寫恰好足夠的代碼新添加的測試之所以會失敗，是因為它指出了系統應該有但尚未實現的功能。我們應該只用花幾分鐘就能實現這項功能，測試失敗的狀態不應持續太長時間。注意：寫恰巧足夠的代碼是為了讓測試盡快通過。因此當前的實現方式可能不是最優。待功能實現、測試通過后，再來解決這個問題的。有測試做保障，就可以進行重構。3、重構重審現有的代碼設計，以改進優化。為何測試驅動開發TDD是一種設計和開發方法，它能幫我們從項目開始就構建出可運行的軟件，以增量的方式添加新功能，使軟件在整個開發過程中都能工作良好。通過演進式設計，并且應用重構優化每一步的設計，我們可以防止代碼質量隨著時間推移而下降。高覆蓋率的自動化單元測試又是軟件的一道安全網。TDD能幫我們正確的做事。

一、增量式開發

所有敏捷軟件開發過程，即要保證軟件可隨時可發布，且每天都能持續產生可部署的版本。下圖描述的過程中，已完成且測試過的功能不斷地累積。在每個時間點上，都只有少量的功能尚未完成或集成。很多項目會推遲交付日期或者交付質量不過關，是因直到最后一刻開發人員還在趕工。TDD可以解決這個問題。在TDD過程中，我們會小步地前進。每一小步都會產生一個工作良好的產品，每一步(以分鐘計算)都會距離目標更近一些。

在迭代、增量式的開發過程中，我們需要不斷地在“實現新功能”和為支持新功能而“調整設計乃至架構”兩項任務間來回切換。演進式設計是指在系統不斷添加更多的功能和行為的過程中，不斷地微調代碼結構。在代碼生命周期的任何時刻，代碼所展現的都是開發人員為實現現有功能所做的最好的設計。用這種方法，我們可以演化出能經受實踐檢驗的架構。

二、重構以保持代碼的健康

在小步前進的過程中，會不斷擴展當前的設計以支持新功能，也會不斷拋棄舊概念，引進新概念。這種情況下，軟件的設計必然會變得很不一致。但通過重構，既可以演進式地設計，又能保持系統設計不出問題。具體重構方法可參考Martin Fowler的著作《重構：改善既有代碼的設計》，本文僅介紹重構原則：1、重構是種紀律嚴明的方法重構是指用某種嚴格的方式重構代碼。重構或許會顯著地改變當前設計，不過這種改變總是小步進行的，而且每一步都會驗證代碼的行為沒有改變。2、重構是種轉換過程重構是兩種狀態間的轉換。在初始狀態中，代碼的設計存在一定問題，而在目標狀態中這些問題都已被修復。3、重構會改變內部結構重構用于改變系統內部結構—代碼，因此大部分重構手法都會涉及實現細節。4、重構保持原有行為無論怎么修改代碼，所變化的都只有代碼的設計和內部結構，外部可見的行為和功能會維持原樣。換言之，代碼的用戶應當對重構毫無察覺。如何確定重構沒有改變系統的外部行為呢？測試可以確保軟件正常運行。

三、通過自動化測試保證軟件正常運行

實施TDD過程中會編寫大量的單元測試用例。而高覆蓋率的單元測試可作為自動化回歸測試，成為重構的安全網，保證重構工作不破壞已有的功能。1、用自動化測試做保護在整個開發過程中，回歸測試會被反復執行許多遍，以保證系統已有功能正常運行。自動化回歸測試必須容易、快速地執行。如果開發人員在每次微小變動后都運行自動化測試，可以精確地定位問題。2、快速獲得反饋通過與“持續集成”提交構建流水線結合，提交代碼前運行與本次改動相關的單元測試，通過質量門禁判斷代碼能否提交版本管理系統，以快速反饋。如何測試驅動開發如何實施TDD，如何編寫及通過測試，首先應從選擇測試開始。1、選擇測試技巧

• 深入細節與整體考慮

細節優先：有利于降低風險，但處理細節問題有時會耽擱總體進度。

整體優先：能夠很快的驗證總體設計，但推遲了細節方面的工作進度。

• 探索未知與輕車熟路

減少不確定性是我們選擇測試時要考慮的因素之一。也可以先挑選熟悉的測試，再處理不確定性較多的測試。

• 最大限度地獲取價值與摘取現成的成果

應當挑選那些工作量最少，回報卻最多的測試。開發基本功能需要更多的時間精力，價值也更大。防御出錯的功能、處理null輸入，這些都很容易實現，但價值也小很多。

• 走通基本功能路徑(happy path)與先處理出錯情況

通常，會先完成基本功能，然后再處理出錯情形有時也存在需要把基本功能放在一邊，先處理所有的出錯情況綜上，測試的選擇沒有一個標準答案，但首先應從簡單的測試入手。2、實現功能技巧使測試通過也有很多途徑，在著名的Test-Driven Development by Example一書中，Kent Beck列舉了3種實現方式：偽實現(faking it)、三角法(Triangulation)以及顯而易見的實現(obvious implementation)。

• 偽實現

寫完測試時，我們并不總是清楚如何正確的實現功能使測試通過。這時候，我們可能會先偽實現某個功能，盡快回到綠的狀態。返回硬編碼的值可能是最簡單的偽實現方法。在偽實現某個功能后，我們可以很容易地切換到“三角法”模式，因為產品代碼中絕不能包含硬編碼的值，所以要想方設法清除掉硬編碼部分，使用真實的實現。為達目的，我們需要寫一個新的測試。

• 三角法

使用三角法來清楚產品代碼中硬編碼的字符串。若還不清楚如何總結歸納出某段硬編碼的應用邏輯，則可以用三角法向正確的實現逐漸演進。“三角法”， 正如電視中的經查們利用手機信號追蹤犯罪嫌疑人。警察們從多點檢測疑犯的信號進行三角定位。已知觀測點的位置，警察們就可以在地圖上標出兩條線，線的焦點則為疑犯位置。我們每寫一個測試，都會在一個維度上約束了可能的解決方案。當測試足夠多時，如下圖，測試就能有效地縮減解空間，三角定位出我們期望的實現。

• 顯而易見的實現

通過測試的方法顯而易見時，可以快速前進，直接做實現。3、測試驅動的基本準則

• 絕不跳過重構

若不能徹底地重構，代碼中仍舊會存在重復。因此，不要跳過重構。

• 盡快變綠

測試驅動時，要用最簡單的方法解決手中的問題。重構時再考慮優化設計。

• 出錯后放慢腳步

開發人員在實踐TDD的過程中會自然地逐漸增大步伐，以至于出現錯誤。這時應小步前進，徹底的重構。4、提高設計的可測試性在寫代碼前編寫測試確實可提高代碼的可測試性，但掌握哪些設計會提高可測試性更為重要。現列舉幾條提高測試性的設計準則：盡量使用組合而非繼承、避免使用static關鍵字、隔離依賴、注入依賴等。5、單元測試模式單元測試是TDD中的重要一環。單元測試的粒度，針對的是一個業務場景(或者說是一個分支)，即業務上的單元，非技術上的單元。同時除了調用時間過長、訪問了外部環境，以及結果不確定的場景以外，其余場景不應該使用mock。對于單元測試所指的“單元”，我們過去有很多不同的理解，比如單元指的是一個類，或者一個方法，此次明確“單元”指的是業務功能單元，將為我們開展單元測試提供了一個清晰的、準確的切入點。其余單元測試相關知識不在本文中介紹。附Mock分類：

測試驅動開發與DevOps持續集成流水線結合實施TDD的開發團隊必須更頻繁地與代碼庫保持同步，即持續集成。通過在開發者平臺配置提交構建流水線和DOD質量門禁，有效檢驗TDD代碼質量。當前已在項目中應用的指標包括：

• 變更行覆蓋率，閾值100%。

• 增量程序案例執行成功率，閾值100%。

• 增量技術規范問題，閾值為無主要、嚴重、阻塞問題。

• 增量Sonar問題，閾值為無嚴重、阻塞問題。

代碼覆蓋率是用來衡量自動化測試對產品代碼的語句、分支及表達式等的覆蓋程度的指標。在提交構建流水線中檢測代碼覆蓋率，及單元測試執行結果，就可以清楚了解測試的充分性。提交構建報告如下圖

中心聚富通和智能小象項目組自7月版全面采用TDD研發模式，差旅和黨建項目組針對核心功能模塊試點TDD研發模式。

一、實施效果

抽取智能小象數據進行TDD效果分析如下：1、手工測試發現缺陷數量逐月下降智能小象項目自7月版采用TDD研發模式以來測試質量有顯著提升，每個版本的手工測試發現的缺陷數量在逐月下降。如下圖：

2、千行代碼缺陷密度逐月下降

二、通過組織單元測試用例評審保證測試先行度

當前暫未啟用開發者平臺DOD門禁中的“測試先行”指標，而是在編碼前組織由需求、開發、測試共同參與的UTDD Reviw單元測試用例評審，來確保測試先行。并使需求、開發、測試在研發前期對需求達成一致，減少返工率。

三、在敏捷迭代研發模式中應用TDD

在迭代周期內采用TDD的研發模式，附聚富通項目組迭代內研發測試工作詳情。

四、下一步工作

1、將繼續推動各研發部門需遵照中心測試驅動開發工作指引，做好單元測試腳本設計工作，夯實開發質量，組織好單元測試驅動開發方案與腳本的評審工作。2、對中心測試驅動開發實施情況進行評價，當前已有評價指標包括測試先行度、變更程序覆蓋率(變更程序的行覆蓋率、變更程序的分支覆蓋率、核心程序的變更行覆蓋率)、提交功能測試首日準入通過率等。3、調研驗收測試驅動開發(ATDD)和行為驅動開發(BDD)。

END

總結

以上是生活随笔為你收集整理的测试驱动开发_DevOps之浅谈测试驱动开发的全部內容，希望文章能夠幫你解決所遇到的問題。

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