測試計劃驅動開發模式 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）