相信大部分開發(fā)團(tuán)隊都在使用TDD况毅，并且還有很多開發(fā)團(tuán)隊都 對外聲明 在使用 TDD 開發(fā)模式摄凡。

之所以說是“對外聲明”，是因為很多開發(fā)團(tuán)隊雖然號稱使用的是 TDD 開發(fā)模式葫掉，實(shí)際開發(fā)過程中卻無法滿足 TDD 的要求涵紊。

實(shí)際上留美，測試驅(qū)動的開發(fā)模式確實(shí)有效竿音，它將可能發(fā)生的問題用測試代碼預(yù)先解決冯键，只有通過測試代碼后的代碼才是可以接受菲语。當(dāng)前有很多公司都在應(yīng)用 TDD妄辩，但 TDD 并不是一個開發(fā)者友好的開發(fā)模式惑灵，只是一個理想化的開發(fā)模式。

為什么 TDD 不是一個開發(fā)者友好的開發(fā)方式眼耀？

大家都知道 TDD 是什么英支，可是試問所有的開發(fā)者能保證每次開發(fā)過程中會滿足 TDD 的要求嗎？

聽聽大家的聲音：

• 測試也只是保證腦內(nèi)想法轉(zhuǎn)成代碼的時候哮伟，邏輯自洽
• 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，但是過度測試是存在
• 大多數(shù)程序員還不會寫測試用例
• 看起來容易楞黄，但是做起來難
• Yes. TDD 該死池凄。TDD 死了，T 才能正常 T鬼廓，程序員做正常人修赞，團(tuán)隊做正常團(tuán)隊。TDD 死桑阶，不是因為程序員達(dá)不到它的要求柏副，是它沒打算尊重程序員，尊重開發(fā)實(shí)際蚣录。TDD 本末倒置的價值觀割择，非生產(chǎn)代碼統(tǒng)治生產(chǎn)代碼，沒理解問題就想對問題高屋建瓴萎河，TDD 是碼農(nóng)界的納粹荔泳，流程方法論原教旨主義。
• TDD 是否已死先不說虐杯，很多程序員連寫出基本的整潔代碼都做不到玛歌，還能指望他先寫測試嗎
• 新手看到 TDD 會歡欣鼓舞，但是他們沒有能力來實(shí)踐擎椰。老手們在項目的壓力下支子，早就麻木了，先寫 case 還不如寫好代碼再補(bǔ) case 呢达舒，很多東西我還沒時間想清楚值朋，怎么寫 case？不如先寫個小功能先巩搏，邊寫邊改
• 其實(shí)我們所有一切的目的是為了快速的交付有價值昨登，有質(zhì)量的產(chǎn)品或者服務(wù)，贏得公司的生存和發(fā)展空間贯底。為了達(dá)到這個目的丰辣，我們有很多種的手段。但手段不是目的。
• 以國內(nèi)的敏捷實(shí)踐來講笙什，完全達(dá)不到 TDD 的要求
• TDD 力量和問題都源自 test first飘哨。要能 test first，寫代碼之前要想得更清楚得湘；代碼得要有良好的可測試性
• 導(dǎo)致其寫的代碼是為了滿足測試的杖玲，而忽略了代碼質(zhì)量和實(shí)際需求
• 不過顿仇，我還真是見過使用 TDD 開發(fā)的不錯的項目淘正，只不過那個項目比較簡單了。更多的情況下臼闻，我看到的是教條式的生硬的 TDD鸿吆，所以，不奇怪地聽到了程序員們的抱怨——“自從用了 TDD述呐，工作量更大了”惩淳。當(dāng)然，這也不能怪他們乓搬，TDD 本來就是很難把控的方法思犁。
• 等等等等

來自于網(wǎng)絡(luò)

我相信很多人都做不到，現(xiàn)在更多的開發(fā)者做的更多的是 Unit Test进肯，就是寫業(yè)務(wù)代碼完了之后再寫（單元）測試激蹲，而這個 Unit Testing 單元測試與 TDD 測試驅(qū)動開發(fā) 的結(jié)果一致，即兩者都保證了功能通過了測試江掩，兩者結(jié)果一樣為什么還給自己添麻煩学辱，提前寫測試代碼呢？

還有些開發(fā)者由于水平不足环形；或是不會測試策泣；有些項目非常緊急根本沒時間做測試。

很多開發(fā)者都很反感 TDD抬吟，至少是在潛意識中很反感（除了自身每天用不著 TDD 那些人）; 試想你在小時候萨咕，每天上學(xué)前媽媽都會在耳邊絮叨都要你小心，然后告訴你每一步的步驟火本，每一步都要正確任洞，有時候真的很煩，于是我們左耳朵進(jìn)右耳朵出发侵，就會不耐煩的說“好了交掏，好了，我知道了”刃鳄；程序員也是一樣的盅弛，對于很繁瑣的一些開發(fā)模式他們會糊弄過去，方法之一就是先寫完業(yè)務(wù)代碼，完成業(yè)務(wù)再說測試挪鹏，寫完后再寫單元測試见秽，把 TDD 給搪塞過去。

可是你知道你媽媽對你是好的讨盒，而且她在養(yǎng)你解取，所以就沒說什么；程序員和公司的關(guān)系與之很相似返顺，公司也在養(yǎng)你禀苦，它希望你寫的代碼是好的，是可靠的遂鹊，所以它要求你用 TDD 的方式編寫代碼振乏。

TDD 看似有效，但是開發(fā)者的普遍不愿意做秉扑，并且很容易造假（很多人都是先寫完代碼慧邮，再寫測試代碼），而且無法監(jiān)督開發(fā)者是否采用 TDD 這種開發(fā)模式舟陆，也就是說 TDD 是理想化的開發(fā)模式误澳，如果要執(zhí)行起來是最好不過的，但是真正嚴(yán)格執(zhí)行的團(tuán)隊又有多少呢秦躯？確定所有的開發(fā)人員都嚴(yán)格執(zhí)行嗎忆谓？

由此得知，TDD 是非常理想化的開發(fā)模式宦赠，只有特定的程序員陪毡、團(tuán)隊、產(chǎn)品和公司才適合這種理想化的開發(fā)模式

除了 TDD勾扭，我們還有哪些替代方案毡琉？

有，目前有種開發(fā)模式正在被一些公司的部門使用妙色，就是 Test Plan Driven Development桅滋，即測試計劃驅(qū)動開發(fā)模式，或是 Test Pre-Requisition Driven Development身辨，即測試前提驅(qū)動開發(fā)丐谋。

TPDD 到底是什么？

相比每次開發(fā)之前先寫測試代碼煌珊，我們可以讓開發(fā)人員參與編寫測試計劃号俐，也就是說，在收到項目需求時定庵，開發(fā)者需要幫助測試人員根據(jù)項目需求思考測試計劃吏饿，并起草 測試計劃 A (或者叫做開發(fā)承諾 -Development Promise)踪危，然后再進(jìn)行開發(fā)。

如果對軟件測試猪落、接口測試贞远、自動化測試、性能測試笨忌、LR腳本開發(fā)蓝仲、面試經(jīng)驗交流。感興趣可以175317069官疲，群內(nèi)會有不定期的發(fā)放免費(fèi)的資料鏈接袱结，這些資料都是從各個技術(shù)網(wǎng)站搜集、整理出來的袁余，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我擎勘，我會注明出處之后分享給大家咱揍。

由于開發(fā)者需要跟測試人員合作颖榜，開發(fā)者相對于測試人員更加了解項目需求，測試計劃更多的依賴于開發(fā)者煤裙，而測試計劃掩完、開發(fā)承諾是受到審查的；所以也造不了假硼砰，對于團(tuán)隊 lead 負(fù)責(zé)人而言是可監(jiān)控且蓬、可調(diào)查的。

適用對象

• 不喜歡怎么 TDD 開發(fā)模式的開發(fā)者题翰，和相關(guān)的團(tuán)隊和企業(yè)
• 沒有嚴(yán)格要求按照 TDD恶阴，然而對外聲稱使用 TDD 開發(fā)模式的開發(fā)者，和相關(guān)團(tuán)隊和企業(yè)
• 執(zhí)行了 TDD 這種開發(fā)模式豹障，然而質(zhì)量沒有明顯的提高的團(tuán)隊和企業(yè)
• 使用 TDD 導(dǎo)致開發(fā)效率降低的團(tuán)隊和企業(yè)
• 開發(fā)者不喜歡 TDD 這種開發(fā)模式冯事，嫌麻煩，但是還想要保證代碼質(zhì)量的團(tuán)隊或企業(yè)
• 開發(fā)者沒有足夠的能力進(jìn)行 TDD 的團(tuán)隊和企業(yè)
• 產(chǎn)品的截止日期很緊張的企業(yè)
• 初創(chuàng)團(tuán)隊和企業(yè)
• 正在上升期的團(tuán)隊和企業(yè)
• 還沒有應(yīng)用 TDD 這種開發(fā)模式血公，但是準(zhǔn)備使用 TDD 的團(tuán)隊或企業(yè)

什么是開發(fā)承諾和測試計劃 A

開發(fā)承諾類似于 design doc昵仅，不過其中講述了開發(fā)者必須完成的功能，需要做的功能以及可選做的功能累魔，并且還提供了測試人員需要做的事情摔笤。

開發(fā)承諾 — 測試計劃 A 如下所示：

• Must Have – Critical Check Points
  • 必須要全部完成的功能點(diǎn)，不完成工作沒有完成
    • 測試人員重點(diǎn)測試的功能點(diǎn)垦写，并且 adhoc test吕世，有能力的團(tuán)隊需要加入自動化測試
• Need Have – Important Check Points
  • 重要的功能點(diǎn)，必須要完成絕大部分的功能梯投，沒有完成絕大部分命辖，工作沒有完成
    • 測試人員重點(diǎn)測試的功能點(diǎn)
• Should Have – Optional Check Points
  • 可選的功能渴析，開發(fā)者可選
    • 測試人員手動測試

開發(fā)承諾和測試計劃 A 有什么作用？

• 開發(fā)承諾 測試計劃 A 的第一個作用是吮龄，開發(fā)者 (測試者) 對于任務(wù)的優(yōu)先級有很清晰的認(rèn)識

  • 為了給開發(fā)者自己看的（或是其他開發(fā)者俭茧，假如開發(fā)者離職或是請假，其他開發(fā)者就可以看測試計劃迅速開發(fā)）漓帚，作為開發(fā)時的指導(dǎo)手冊母债，這樣開發(fā)者的頭緒就更加清晰，也知道任務(wù)的優(yōu)先級 ---- 先做什么尝抖，后做什么毡们。

  • 為了給測試人員看的，作為測試的指導(dǎo)手冊昧辽，這樣測試人員就知道什么功能需要重點(diǎn)測試衙熔、什么東西需要進(jìn)行實(shí)驗性的測試，以及什么功能需要實(shí)現(xiàn)測試自動化以便于加入到 CI 和 CD 之中搅荞。

• 開發(fā)承諾 測試計劃 A 的第二個作用是红氯，承諾使開發(fā)者的開發(fā)過程更加小心

  • 將測試計劃 A 交給測試人員和開發(fā)組長，利用心理學(xué)中“承諾”作用咕痛，使自己的言行和承諾一致痢甘。這樣的話，開發(fā)人員就知道自己的 code 至少要滿足什么條件茉贡，至少要過什么樣的測試塞栅，所以開發(fā)時會更加小心，代碼的質(zhì)量和可靠性也會得到很高的提升腔丧。

• 開發(fā)承諾 測試計劃 A 的第三個作用是放椰，促進(jìn)測試人員的工作進(jìn)度，使測試人員有更多的時間進(jìn)行自動化愉粤、adhoc 測試或是運(yùn)維方面的工作

  • 測試人員會根據(jù)測試計劃 A 起草測試計劃 B砾医，只需要在測試計劃 B 中添加如何進(jìn)行測試即可。

參考：一旦我們做出了某種承諾科汗，或是選擇了某種立場藻烤，就會在個人和外部環(huán)境的壓力下，迫使自己的言行與承諾保持一致头滔，盡管這種行為有悖于自己的意愿怖亭。

TDD 和 TPDD 有什么區(qū)別？

TDD 的優(yōu)缺點(diǎn)

TDD 是先寫測試代碼坤检，判斷業(yè)務(wù)代碼是否可以通過測試代碼兴猩。看似有效早歇，但是開發(fā)者的普遍不愿意做倾芝，或是完成度很差讨勤，或是做了之后導(dǎo)致沒有按時完成任務(wù)；并且很容易造假晨另，很多人都是先寫完代碼潭千，再寫測試代碼；或者測試代碼質(zhì)量不高借尿；或是測試用例不好刨晴。

對于管理者而言，他們無法監(jiān)督開發(fā)者是否有效的沿用 TDD 這種開發(fā)模式路翻，完全體現(xiàn)不了 TDD 的優(yōu)勢狈癞。

TPDD 的優(yōu)缺點(diǎn)

1. 提高代碼質(zhì)量

   • TPDD 是先寫開發(fā)承諾，使開發(fā)者對測試用例和測試環(huán)境有清晰的認(rèn)識茂契，思維會更加清晰有條理蝶桶；并且由于承諾的心理作用，開發(fā)者會潛移默化的提高代碼質(zhì)量掉冶。

2. 可監(jiān)控和不可造假

   • 因為測試人員需要根據(jù)開發(fā)者的開發(fā)承諾編寫測試計劃真竖，可以使管理者很直接的監(jiān)督開發(fā)者是否采用 TPDD 這種開發(fā)模式（通過審查開發(fā)承諾），所以不可能造假郭蕉。

3. 有時間進(jìn)行其他方面的提升疼邀，例如自動化喂江、運(yùn)維等

   • 由于開發(fā)者和測試者已經(jīng)將基本的開發(fā)承諾—測試計劃 B 寫出來了召锈，對于測試者來說將會用更少的時間做功能的理解和測試的準(zhǔn)備，這將給測試人員更多的時間進(jìn)行 adhoc 測試获询、自動化測試或是運(yùn)維功能的開發(fā)和維護(hù)涨岁。

4. 更好的接受 TDD

   • 由于開發(fā)者已經(jīng)接觸了測試，使用 TPDD 后的團(tuán)隊會更好的接受 TDD吉嚣，這時 TPDD 又可以被稱為 Test pre-requisition Driven Development梢薪。

5. 對開發(fā)者友好

   • 相對于每次開發(fā)之前寫測試代碼，只需要與測試人員想出測試用例尝哆，對于開發(fā)者來說這是更加容易的

6. 對測試人員友好

   • 因為與開發(fā)者的直接合作秉撇，測試的準(zhǔn)備的難度大大的降低，測試計劃和測試用例的思考時間縮短秋泄，并且有時間空余去做一些自動化或是運(yùn)維方面的工作琐馆。

7. 對管理人員友好

   • 由于開發(fā)承諾和測試計劃的實(shí)體化，管理人員就可以提前進(jìn)行審查恒序，而不是等待開發(fā)結(jié)束后進(jìn)行代碼審查（code review）