測試計劃驅動開發模式 TPDD：一種比 TDD 更友好的開發模式

相信大部分開發團隊都在使用TDD，而且還有不少開發團隊都 對外聲明 在使用 TDD 開發模式。

之因此說是「對外聲明」，是由於不少開發團隊雖然號稱使用的是 TDD 開發模式，實際開發過程當中卻沒法知足 TDD 的要求。

實際上，測試驅動的開發模式確實有效，它將可能發生的問題用測試代碼預先解決，只有經過測試代碼後的代碼纔是能夠接受。當前有不少公司都在應用 TDD，但 TDD 並非一個開發者友好的開發模式，只是一個理想化的開發模式。

爲何 TDD 不是一個開發者友好的開發方式？

你們都知道 TDD 是什麼，但是試問全部的開發者能保證每次開發過程當中會知足 TDD 的要求嗎？

聽聽你們的聲音：

• 測試也只是保證腦內想法轉成代碼的時候，邏輯自洽
• Lots of people on the internet talk about how good TDD is, but people were afraid to say it wasn’t working for them.
• 沒有 deadline 的威脅，我很喜歡 TDD，可是過分測試是存在
• 大多數程序員還不會寫測試用例
• 看起來容易，可是作起來難
• Yes. TDD 該死。TDD 死了，T 才能正常 T，程序員作正常人，團隊作正常團隊。TDD 死，不是由於程序員達不到它的要求，是它沒打算尊重程序員，尊重開發實際。TDD 本末倒置的價值觀，非生產代碼統治生產代碼，沒理解問題就想對問題高屋建瓴，TDD 是碼農界的納粹，流程方法論原教旨主義。
• TDD 是否已死先不說，不少程序員連寫出基本的整潔代碼都作不到，還能期望他先寫測試嗎
• 新手看到 TDD 會歡欣鼓舞，可是他們沒有能力來實踐。老手們在項目的壓力下，早就麻木了，先寫 case 還不如寫好代碼再補 case 呢，不少東西我還沒時間想清楚，怎麼寫 case？不如先寫個小功能先，邊寫邊改
• 其實咱們全部一切的目的是爲了快速的交付有價值，有質量的產品或者服務，贏得公司的生存和發展空間。爲了達到這個目的，咱們有不少種的手段。但手段不是目的。
• 以國內的敏捷實踐來說，徹底達不到 TDD 的要求
• TDD 力量和問題都源自 test first。要能 test first，寫代碼以前要想得更清楚；代碼得要有良好的可測試性
• 致使其寫的代碼是爲了知足測試的，而忽略了代碼質量和實際需求
• 不過，我還真是見過使用 TDD 開發的不錯的項目，只不過那個項目比較簡單了。更多的狀況下，我看到的是教條式的生硬的 TDD，因此，不奇怪地聽到了程序員們的抱怨——「自從用了 TDD，工做量更大了」。固然，這也不能怪他們，TDD 原本就是很難把控的方法。
• 等等等等

來自於網絡

我相信不少人都作不到，如今更多的開發者作的更多的是 Unit Test，就是寫業務代碼完了以後再寫（單元）測試，而這個 Unit Testing 單元測試與 TDD 測試驅動開發 的結果一致，即二者都保證了功能經過了測試，二者結果同樣爲何還給本身添麻煩，提早寫測試代碼呢？

還有些開發者因爲水平不足；或是不會測試；有些項目很是緊急根本沒時間作測試。

不少開發者都很反感 TDD，至少是在潛意識中很反感（除了自身天天用不着 TDD 那些人）; 試想你在小時候，天天上學前媽媽都會在耳邊絮叨都要你當心，而後告訴你每一步的步驟，每一步都要正確，有時候真的很煩，因而咱們左耳朵進右耳朵出，就會不耐煩的說「好了，好了，我知道了」；程序員也是同樣的，對於很繁瑣的一些開發模式他們會糊弄過去，方法之一就是先寫完業務代碼，完成業務再說測試，寫完後再寫單元測試，把 TDD 給搪塞過去。

但是你知道你媽媽對你是好的，並且她在養你，因此就沒說什麼；程序員和公司的關係與之很類似，公司也在養你，它但願你寫的代碼是好的，是可靠的，因此它要求你用 TDD 的方式編寫代碼。

TDD 看似有效，可是開發者的廣泛不肯意作，而且很容易造假（不少人都是先寫完代碼，再寫測試代碼），並且沒法監督開發者是否採用 TDD 這種開發模式，也就是說 TDD 是理想化的開發模式，若是要執行起來是最好不過的，可是真正嚴格執行的團隊又有多少呢？肯定全部的開發人員都嚴格執行嗎？

由此得知，TDD 是很是理想化的開發模式，只有特定的程序員、團隊、產品和公司才適合這種理想化的開發模式

除了 TDD，咱們還有哪些替代方案？

有，目前有種開發模式正在被一些公司的部門使用，就是 Test Plan Driven Development，即測試計劃驅動開發模式，或是 Test Pre-Requisition Driven Development，即測試前提驅動開發。

TPDD 究竟是什麼？

相比每次開發以前先寫測試代碼，咱們可讓開發人員參與編寫測試計劃，也就是說，在收到項目需求時，開發者須要幫助測試人員根據項目需求思考測試計劃，並起草 測試計劃 A (或者叫作開發承諾 -Development Promise)，而後再進行開發。

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

因爲開發者須要跟測試人員合做，開發者相對於測試人員更加了解項目需求，測試計劃更多的依賴於開發者，而測試計劃、開發承諾是受到審查的；因此也造不了假，對於團隊 lead 負責人而言是可監控、可調查的。

適用對象

• 不喜歡怎麼 TDD 開發模式的開發者，和相關的團隊和企業
• 沒有嚴格要求按照 TDD，然而對外聲稱使用 TDD 開發模式的開發者，和相關團隊和企業
• 執行了 TDD 這種開發模式，然而質量沒有明顯的提升的團隊和企業
• 使用 TDD 致使開發效率下降的團隊和企業
• 開發者不喜歡 TDD 這種開發模式，嫌麻煩，可是還想要保證代碼質量的團隊或企業
• 開發者沒有足夠的能力進行 TDD 的團隊和企業
• 產品的截止日期很緊張的企業
• 初創團隊和企業
• 正在上升期的團隊和企業
• 尚未應用 TDD 這種開發模式，可是準備使用 TDD 的團隊或企業

什麼是開發承諾和測試計劃 A

開發承諾相似於 design doc，不過其中講述了開發者必須完成的功能，須要作的功能以及可選作的功能，而且還提供了測試人員須要作的事情。

開發承諾 — 測試計劃 A 以下所示：

• Must Have – Critical Check Points
  • 必需要所有完成的功能點，不完成工做沒有完成
    • 測試人員重點測試的功能點，而且 adhoc test，有能力的團隊須要加入自動化測試
• Need Have – Important Check Points
  • 重要的功能點，必需要完成絕大部分的功能，沒有完成絕大部分，工做沒有完成
    • 測試人員重點測試的功能點
• Should Have – Optional Check Points
  • 可選的功能，開發者可選
    • 測試人員手動測試

開發承諾和測試計劃 A 有什麼做用？

• 開發承諾 測試計劃 A 的第一個做用是，開發者 (測試者) 對於任務的優先級有很清晰的認識

  • 爲了給開發者本身看的（或是其餘開發者，假如開發者離職或是請假，其餘開發者就能夠看測試計劃迅速開發），做爲開發時的指導手冊，這樣開發者的頭緒就更加清晰，也知道任務的優先級 ---- 先作什麼，後作什麼。

  • 爲了給測試人員看的，做爲測試的指導手冊，這樣測試人員就知道什麼功能須要重點測試、什麼東西須要進行實驗性的測試，以及什麼功能須要實現測試自動化以便於加入到 CI 和 CD 之中。

• 開發承諾 測試計劃 A 的第二個做用是，承諾使開發者的開發過程更加當心

  • 將測試計劃 A 交給測試人員和開發組長，利用心理學中「承諾」做用，使本身的言行和承諾一致。這樣的話，開發人員就知道本身的 code 至少要知足什麼條件，至少要過什麼樣的測試，因此開發時會更加當心，代碼的質量和可靠性也會獲得很高的提高。

• 開發承諾 測試計劃 A 的第三個做用是，促進測試人員的工做進度，使測試人員有更多的時間進行自動化、adhoc 測試或是運維方面的工做

  • 測試人員會根據測試計劃 A 起草測試計劃 B，只須要在測試計劃 B 中添加如何進行測試便可。

參考：一旦咱們作出了某種承諾，或是選擇了某種立場，就會在我的和外部環境的壓力下，迫使本身的言行與承諾保持一致，儘管這種行爲有悖於本身的意願。

TDD 和 TPDD 有什麼區別？

TDD 的優缺點

TDD 是先寫測試代碼，判斷業務代碼是否能夠經過測試代碼。看似有效，可是開發者的廣泛不肯意作，或是完成度不好，或是作了以後致使沒有按時完成任務；而且很容易造假，不少人都是先寫完代碼，再寫測試代碼；或者測試代碼質量不高；或是測試用例很差。

對於管理者而言，他們沒法監督開發者是否有效的沿用 TDD 這種開發模式，徹底體現不了 TDD 的優點。

TPDD 的優缺點

1. 提升代碼質量

   • TPDD 是先寫開發承諾，使開發者對測試用例和測試環境有清晰的認識，思惟會更加清晰有條理；而且因爲承諾的心理做用，開發者會潛移默化的提升代碼質量。

2. 可監控和不可造假

   • 由於測試人員須要根據開發者的開發承諾編寫測試計劃，可使管理者很直接的監督開發者是否採用 TPDD 這種開發模式（經過審查開發承諾），因此不可能造假。

3. 有時間進行其餘方面的提高，例如自動化、運維等

   • 因爲開發者和測試者已經將基本的開發承諾—測試計劃 B 寫出來了，對於測試者來講將會用更少的時間作功能的理解和測試的準備，這將給測試人員更多的時間進行 adhoc 測試、自動化測試或是運維功能的開發和維護。

4. 更好的接受 TDD

   • 因爲開發者已經接觸了測試，使用 TPDD 後的團隊會更好的接受 TDD，這時 TPDD 又能夠被稱爲 Test pre-requisition Driven Development。

5. 對開發者友好

   • 相對於每次開發以前寫測試代碼，只須要與測試人員想出測試用例，對於開發者來講這是更加容易的

6. 對測試人員友好

   • 由於與開發者的直接合做，測試的準備的難度大大的下降，測試計劃和測試用例的思考時間縮短，而且有時間空餘去作一些自動化或是運維方面的工做。

7. 對管理人員友好

   • 因爲開發承諾和測試計劃的實體化，管理人員就能夠提早進行審查，而不是等待開發結束後進行代碼審查（code review）