本篇內(nèi)容主要講解“怎么理解TDD”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“怎么理解TDD”吧!

按需策劃可以根據(jù)自己的需求進(jìn)行定制，網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)構(gòu)思過(guò)程中功能建設(shè)理應(yīng)排到主要部位公司網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)的運(yùn)用實(shí)際效果公司網(wǎng)站制作網(wǎng)站建立與制做的實(shí)際意義

當(dāng)前國(guó)內(nèi)很多軟件開(kāi)發(fā)人員對(duì)于TDD的理解比較模糊，大部分人也沒(méi)有明確和有意識(shí)的去實(shí)施TDD，應(yīng)此很多人都有著不同的理解。

其中最經(jīng)典的理解就是基于代碼的某個(gè)單元，使用Mock等技術(shù)編寫(xiě)單元測(cè)試，然后用這個(gè)單元測(cè)試來(lái)驅(qū)動(dòng)開(kāi)發(fā)，抑或是幫助在重構(gòu)、修改以后進(jìn)行回歸測(cè)試。而現(xiàn)在大部分反對(duì)TDD的聲音就是基于這個(gè)理解，比如：

• 工期緊，時(shí)間短，寫(xiě)TDD太浪費(fèi)時(shí)間；

• 業(yè)務(wù)需求變化太快，修改功能都來(lái)不及，根本沒(méi)有時(shí)間來(lái)寫(xiě)TDD；

• 寫(xiě)TDD對(duì)開(kāi)發(fā)人員的素質(zhì)要求非常高，普通的開(kāi)發(fā)人員不會(huì)寫(xiě)；

• TDD 推行的最大問(wèn)題在于大多數(shù)程序員還不會(huì)「寫(xiě)測(cè)試用例」和「重構(gòu)」；

• 由于大量使用Mock和Stub技術(shù)，導(dǎo)致UT沒(méi)有辦法測(cè)試集成后的功能，對(duì)于測(cè)試業(yè)務(wù)價(jià)值作用不大

• ......

總結(jié)一下，技術(shù)人員拒絕TDD的主要原因在于難度大、工作量大、Mock的大量使用導(dǎo)致很難測(cè)試業(yè)務(wù)價(jià)值等。

這些理解主要是建立在片面的理解和實(shí)踐之上，而在我的認(rèn)知中，TDD的核心是：先寫(xiě)測(cè)試，并使用它幫助開(kāi)發(fā)人員來(lái)驅(qū)動(dòng)軟件開(kāi)發(fā)。

首先是先寫(xiě)測(cè)試，這里的測(cè)試并不只是單元測(cè)試，也不是說(shuō)一定要使用mock和stub來(lái)做測(cè)試。這里的測(cè)試就是指軟件測(cè)試本身，可以是基于代碼單元的單元測(cè)試，可以是基于業(yè)務(wù)需求的功能測(cè)試，也可以是基于特定驗(yàn)收條件的驗(yàn)收測(cè)試。

其次是幫助開(kāi)發(fā)人員，主要是幫助開(kāi)發(fā)人員理解軟件的功能需求和驗(yàn)收條件，幫助其思考和設(shè)計(jì)代碼，從而達(dá)到驅(qū)動(dòng)開(kāi)發(fā)的目的，所以TDD是包含兩部分：ATDD與UTDD。

ATDD（Acceptance Test Driven Development）：驗(yàn)收驅(qū)動(dòng)測(cè)試開(kāi)發(fā)，首先BA或者QA編寫(xiě)驗(yàn)收測(cè)試用例，然后Dev通過(guò)驗(yàn)收測(cè)試來(lái)理解需求和驗(yàn)收條件，并編寫(xiě)實(shí)現(xiàn)代碼直到驗(yàn)收測(cè)試用例通過(guò)。

由于驗(yàn)收方法和類(lèi)型也是多種多樣的，所以根據(jù)驗(yàn)收方法和類(lèi)型的不同，ATDD其實(shí)是包含BDD（Behavior Driven Development）、EDD（Example Driven Development），F(xiàn)DD（Feature Driven Development）、CDCD（Consumer Driven Contract Development）等各種的實(shí)踐方法。

比如以軟件的行為為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是BDD；如果以特定的實(shí)例數(shù)據(jù)為驗(yàn)收標(biāo)準(zhǔn)，這個(gè)是EDD；如果以Web Service API消費(fèi)者提出API契約來(lái)驅(qū)動(dòng)API提供者開(kāi)發(fā)API，這個(gè)是CDCD等。所以ATDD的具體實(shí)現(xiàn)需要結(jié)合項(xiàng)目的實(shí)際情況來(lái)選用適合的驗(yàn)收測(cè)試方法與類(lèi)型。

UTDD（Unit Test Driven Development）：單元驅(qū)動(dòng)測(cè)試開(kāi)發(fā)，首先Dev編寫(xiě)單元測(cè)試用例，然后編寫(xiě)實(shí)現(xiàn)代碼直到單元測(cè)試通過(guò)。這個(gè)就是現(xiàn)在很多人所謂的TDD、實(shí)踐的TDD、喜歡的TDD、抱怨的TDD，但是它卻只是真正意義上TDD的一部分而已。

TDD金字塔

再來(lái)看看David 的《TDD is dead. Long live testing》，他主要是認(rèn)為T(mén)DD大量使用mock，導(dǎo)致無(wú)法測(cè)試軟件連接了數(shù)據(jù)庫(kù)之后的功能，進(jìn)而無(wú)法測(cè)試其業(yè)務(wù)價(jià)值。

其次他提出應(yīng)該使用”Long live testing”, 而他并沒(méi)有說(shuō)明這種測(cè)試應(yīng)該是在編寫(xiě)代碼之前還是之后寫(xiě)，以及會(huì)不會(huì)用來(lái)作為客戶對(duì)于軟件的驗(yàn)收標(biāo)準(zhǔn)。如果他沒(méi)有這樣做，那他只是使用”Long live testing”來(lái)做回歸測(cè)試；如果他做了，那么他也是使用了ATDD，從而使用了TDD。

所以他對(duì)TDD的理解還是狹隘的，認(rèn)為T(mén)DD只是UTDD，導(dǎo)致他寫(xiě)了這篇文章來(lái)批評(píng)TDD。有可能他在現(xiàn)實(shí)工作中已經(jīng)使用了ATDD，也就是TDD。

最后來(lái)看看Kent Beck、Martin Fowler、David關(guān)于Is TDD Dead?的辯論，我覺(jué)得他們所說(shuō)的都有道理，并且也是合理的。原因是他們的背景和行業(yè)不同，本來(lái)對(duì)于不同的行業(yè)和不同的背景就應(yīng)該選擇適合的測(cè)試驅(qū)動(dòng)方法（有可能不一樣）。

首先來(lái)看看Kent Beck，他在Facebook工作，出版過(guò)很多書(shū)，可以定位為一名在大型IT公司工作的軟件思想家。其次是David，一個(gè)標(biāo)準(zhǔn)歐洲帥哥，ROR創(chuàng)造者之一，Basecamp公司的創(chuàng)始人和CTO，Basecamp是一個(gè)只有幾十個(gè)人的小型軟件公司，所以他可以定位是一名創(chuàng)業(yè)者、技術(shù)牛人。

Kent Beck所在的公司開(kāi)發(fā)的是大型復(fù)雜業(yè)務(wù)軟件（Facebook平臺(tái)），代碼量巨大，需要長(zhǎng)時(shí)間（幾年）大量人員（幾十甚至幾百）來(lái)開(kāi)發(fā)和維護(hù)。DHH開(kāi)發(fā)的中小型企業(yè)軟件（比如CRM），代碼量一般，需要快速（幾個(gè)月）、少量人員（幾個(gè)到十幾個(gè)）開(kāi)發(fā)和維護(hù)。

• Kent Beck在金錢(qián)和人力資源相對(duì)充足、時(shí)間相對(duì)充裕的情況下追求的是代碼質(zhì)量，大量人員的良好協(xié)作與平臺(tái)穩(wěn)定。

• DHH卻在金錢(qián)和人力資源相對(duì)較少情況下追求最大化客戶業(yè)務(wù)價(jià)值，使得少量人員能快速開(kāi)發(fā)出軟件并賣(mài)給客戶賺錢(qián)。

所以在Kent Beck所在的環(huán)境下，單元測(cè)試（UTDD）是非常有價(jià)值的；而在DHH所在的環(huán)境下，功能測(cè)試或者ATDD卻更為適合。

國(guó)內(nèi)很多人對(duì)于TDD的狹隘理解還源于很多網(wǎng)上的中文資料，百度百科對(duì)于TDD的解釋就是其中一個(gè)：

TDD的原理是在開(kāi)發(fā)功能代碼之前，先編寫(xiě)單元測(cè)試用例代碼，測(cè)試代碼確定需要編寫(xiě)什么產(chǎn)品代碼。TDD雖是敏捷方法的核心實(shí)踐，但不只適用于XP（Extreme Programming），同樣可以適用于其他開(kāi)發(fā)方法和過(guò)程。

而國(guó)外有不少站點(diǎn)上的資料是對(duì)于TDD是有正確理解的，比如下圖是一個(gè)敏捷調(diào)查表。從其中的“We take a test-driven development(TDD) approach”和”We take a TDD approach at the requirements level”就能發(fā)現(xiàn)其對(duì)TDD的理解就是包含UTDD和ATDD。

TDD不是銀彈，不要期望它能解決任何問(wèn)題，無(wú)論是UTDD、EDD還是BDD，根據(jù)自己項(xiàng)目的實(shí)際情況，比如資金、人力資源、時(shí)間、組織架構(gòu)等，合理的選擇。  

到此，相信大家對(duì)“怎么理解TDD”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)站欄目：怎么理解TDD
URL分享：http://aaarwkj.com/article34/igdsse.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、App設(shè)計(jì)、Google、動(dòng)態(tài)網(wǎng)站、靜態(tài)網(wǎng)站、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)