單元測(cè)試
單元測(cè)試每個(gè)開(kāi)發(fā)者都了解，編寫(xiě)單元測(cè)試的目的在于可以通過(guò)測(cè)試用例自動(dòng)發(fā)現(xiàn)程序某些缺陷，測(cè)試用例越豐富，涵蓋地方越多，程序健壯性越強(qiáng)。很多開(kāi)發(fā)者都是寫(xiě)完代碼再考慮寫(xiě)單元測(cè)試，來(lái)確認(rèn)代碼結(jié)果是否符合預(yù)期。
TDD
TDD全稱Test Drive Development，面向測(cè)試驅(qū)動(dòng)開(kāi)發(fā)。從名字可以得知，TDD是一套開(kāi)發(fā)流程，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)。流程是先確認(rèn)好測(cè)試用例，再編寫(xiě)功能代碼，通過(guò)單元測(cè)試之后再優(yōu)化代碼，優(yōu)化之后代碼再單元測(cè)試，不斷重復(fù)以上步驟直到寫(xiě)出滿意代碼。
在leetcode刷題的時(shí)候，leetcode已經(jīng)為每道題提供好測(cè)試用例了，當(dāng)通過(guò)所有測(cè)試用例之后，證明你的代碼正確，然而你想繼續(xù)挑戰(zhàn)優(yōu)化最小時(shí)間維度和空間復(fù)雜度的話，可以重構(gòu)你的代碼，當(dāng)然，重構(gòu)完也是要通過(guò)單元測(cè)試。
以上就是TDD的一個(gè)例子。
TDD缺點(diǎn)：
1:從開(kāi)發(fā)流程來(lái)講，需要先提供測(cè)試用例，再進(jìn)行開(kāi)發(fā)。但在緊湊業(yè)務(wù)開(kāi)發(fā)過(guò)程中，一般是先開(kāi)發(fā)后測(cè)試，測(cè)試人員最后才介入，如果先要提供測(cè)試用例，必定要需求一開(kāi)始就要非常明確需求細(xì)節(jié)，要能在開(kāi)發(fā)前完整提供測(cè)試用例，難度有點(diǎn)大。
2:TDD沒(méi)有規(guī)定測(cè)試測(cè)試范圍，意味著TDD也是針對(duì)某個(gè)函數(shù)或者某個(gè)功能展開(kāi)的，無(wú)法保證整體設(shè)計(jì)準(zhǔn)確性。
BDD
Behavior Driven Development，行為驅(qū)動(dòng)開(kāi)發(fā)。與TDD不同，BDD不關(guān)注單個(gè)函數(shù)或者功能，更注重整體設(shè)計(jì)的準(zhǔn)確性。而且BDD的測(cè)試用例編寫(xiě)更接近自然語(yǔ)言，較為容易從需求文檔轉(zhuǎn)化為測(cè)試用例，更直觀。
舉例：
給一個(gè)登錄頁(yè)面需求，要求手機(jī)號(hào)為11位，手機(jī)號(hào)長(zhǎng)度少于11位，則登錄按鈕置灰，且不可點(diǎn)擊。
將上述需求轉(zhuǎn)化為BDD測(cè)試用例的話，為以下代碼
describe(@"登錄事件", ^{
context(@"點(diǎn)擊登錄", ^{
it(@"手機(jī)號(hào)長(zhǎng)度符合要求", ^{
// 測(cè)試實(shí)現(xiàn)（執(zhí)行登錄）
});
it(@"手機(jī)號(hào)長(zhǎng)度短了", ^{
// 測(cè)試實(shí)現(xiàn)（登錄按鈕變灰且不可點(diǎn)擊）
});
});
});
BDD對(duì)比優(yōu)點(diǎn)：可以將需求，設(shè)計(jì)，更容易轉(zhuǎn)為測(cè)試用例，而且測(cè)試用例可讀性強(qiáng)，可以當(dāng)作文檔使用，易于維護(hù)。
總結(jié)：
1，TDD和BDD與其說(shuō)是測(cè)試方式，不如說(shuō)是開(kāi)發(fā)方式，區(qū)別在于你要測(cè)試的對(duì)象是什么，TDD針對(duì)函數(shù)，功能，BDD針對(duì)行為，流程。
2，BDD為T(mén)DD的進(jìn)化版，都需要開(kāi)發(fā)前提供測(cè)試用例。
2，基礎(chǔ)類或者SDK的可以使用TDD，BDD更適合整體業(yè)務(wù)開(kāi)發(fā)。
