摘要：理想情況下項(xiàng)目的參與人員能根據(jù)當(dāng)前系統(tǒng)行為列表判斷新加入的功能行為是否會(huì)破壞現(xiàn)有功能。通過暫時(shí)掛起不實(shí)現(xiàn)具體行為，你可以進(jìn)行測試優(yōu)先的開發(fā)。

我們一般將測試放在項(xiàng)目的最后時(shí)刻進(jìn)行，甚至在時(shí)間較緊時(shí)、預(yù)算超支，或者其他原因發(fā)生時(shí)會(huì)放棄測試。

項(xiàng)目的管理者好奇為什么開發(fā)者就是不能一開始就明白（需求、設(shè)計(jì)），而在系統(tǒng)有很多利益相關(guān)者并且不同的相關(guān)者對(duì)系統(tǒng)有不同的看法的時(shí)候，開發(fā)者（特別是在大型項(xiàng)目中），更容易變得迷糊,使得協(xié)商過程像盲人摸象一樣。

每個(gè)項(xiàng)目的開始，必然是有一個(gè)關(guān)于項(xiàng)目行為表現(xiàn)、功能特點(diǎn)的討論會(huì)，由客戶或者其他業(yè)務(wù)人員向開發(fā)團(tuán)隊(duì)解釋他們就行想要什么。（苦逼又令人討厭的策劃....）

有時(shí)候，這些交互、討論以敏捷開發(fā)形式表現(xiàn)；有時(shí)是設(shè)計(jì)文檔，就像去年查理斯-?？怂沟牟┛退f的那樣；有時(shí)是由Keynote制作的流程圖或者模型；有時(shí)甚至是一個(gè)簡單的電話解釋而已。

僅通過這些溝通，開發(fā)者一般只是負(fù)責(zé)構(gòu)建一個(gè)能夠運(yùn)行的系統(tǒng)而已，而這對(duì)于一個(gè)開發(fā)團(tuán)隊(duì)來說，是遠(yuǎn)遠(yuǎn)不夠的。這(單純的溝通)對(duì)于大型系統(tǒng)的業(yè)余開發(fā)人員來說尤其困難。

一般存在一個(gè)爭議：如果客戶/業(yè)務(wù)人員一開始就對(duì)系統(tǒng)的行為、特征有充分的認(rèn)知，那么為什么往往要撤銷對(duì)這些功能、行為進(jìn)行測試？

答案可能非常簡單：測試一般被認(rèn)為是共享資產(chǎn)（對(duì)大家都有用的），也不被認(rèn)為是對(duì)項(xiàng)目開發(fā)有實(shí)際價(jià)值的。測試只對(duì)工程師有用或者只對(duì)特定的一些人有用。

那么如何才能使得測試對(duì)大家都有價(jià)值呢？僅僅是列出系統(tǒng)的功能特性嗎？當(dāng)然不是，我們應(yīng)該使用behavior-driven development (BDD)而不是僅僅是test-driven development (TDD)。

行為驅(qū)動(dòng)開發(fā)應(yīng)該著眼于你的代碼所要實(shí)現(xiàn)的業(yè)務(wù)行為，即“為什么要編寫這樣的代碼？”它可以很好的支撐項(xiàng)目核心工作流程，特別是對(duì)于交叉功能的了解與實(shí)現(xiàn)。

敏捷BDD開發(fā)有很大的好處。當(dāng)開發(fā)者和敏捷項(xiàng)目主或者業(yè)務(wù)分析師坐在一起，將大概功能框框（具體如何實(shí)現(xiàn)由開發(fā)者在框內(nèi)填寫）寫在白板上：

業(yè)務(wù)人員指定系統(tǒng)的行為特性

開發(fā)者基于他們自己對(duì)系統(tǒng)的理解向業(yè)務(wù)人員提問，同時(shí)從開發(fā)者角度寫下其他附加的行為。

理想情況下：項(xiàng)目的參與人員能根據(jù)當(dāng)前系統(tǒng)行為列表判斷新加入的功能行為是否會(huì)破壞現(xiàn)有功能。

我發(fā)現(xiàn)這些簡單的行為給了我一些約束，使得我能像一個(gè)開發(fā)者一樣思考：這些我已經(jīng)實(shí)現(xiàn)的這些測試能夠?qū)⑽业膶?shí)現(xiàn)代碼約束在一個(gè)規(guī)范之中。而那些功能代碼只需滿足這些約束、規(guī)范，就能在協(xié)作開發(fā)中快速完成。

這種協(xié)作方法使得我更加專注于提供給最終用戶的功能特性，而且業(yè)務(wù)人員可以在旁約束、糾正我對(duì)系統(tǒng)行為的理解，而不是系統(tǒng)的具體實(shí)現(xiàn)。這就是BDD和TDD的突出區(qū)別。

情景：你是負(fù)責(zé)開發(fā)企業(yè)會(huì)計(jì)系統(tǒng)的團(tuán)隊(duì)一員，系統(tǒng)使用Rails框架實(shí)現(xiàn)。有一天，業(yè)務(wù)人員問你一個(gè)關(guān)于提醒模塊的功能：提醒用戶他們正在等待處理的發(fā)票。你坐下來和業(yè)務(wù)人員定義這個(gè)功能模塊。

你打開你的文本編輯器/筆記本，開始在上面畫上框框，每個(gè)框代表用戶需要的功能行為：

//為每個(gè)新支票添加一個(gè)提醒日期
it "adds a reminder date when an invoice is created"
//當(dāng)提醒日期到來就發(fā)郵件提醒
it "sends an email to the invoice"s account"s primary contact after the reminder date has passed"
//如果用戶閱讀了郵件就給用戶打上標(biāo)記
it "marks that the user has read the email in the invoice"

在開發(fā)中專注于系統(tǒng)行為使得測試在驗(yàn)證你所實(shí)現(xiàn)系統(tǒng)行為是否正確中是十分有用的，而不僅僅是編碼正確（沒有bug）。要注意的是，這種分析要用業(yè)務(wù)語言而不是實(shí)現(xiàn)系統(tǒng)所采用的具體開發(fā)語言。
你不需要將“發(fā)票屬于哪個(gè)用戶”描述出來，因?yàn)殚_發(fā)團(tuán)隊(duì)之外的人也并不關(guān)心這種關(guān)系。

有些開發(fā)者在討論/開發(fā)現(xiàn)場就寫出測試樣例，在系統(tǒng)中調(diào)用這些所要測試的方法，設(shè)置期望值，如下：

it "adds a reminder date when an invoice is created"  do
  current_invoice = create :invoice
  current_invoice.reminder_date.should == 20.days.from_now
end

這些測試樣例必然是運(yùn)行失敗的，因?yàn)槲覀冞€沒有實(shí)現(xiàn)設(shè)置remind_date的代碼。

我明白開發(fā)者為什么會(huì)寫失敗樣例測試，但是從業(yè)務(wù)人員的角度來說，這寫測試對(duì)他并無用處。一些業(yè)務(wù)人員可能會(huì)被這些測試細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)搞迷糊，甚至我學(xué)得一些開發(fā)知識(shí)后就插手開發(fā)人員的工作。（數(shù)據(jù)庫設(shè)計(jì)、代碼復(fù)用）

從我的經(jīng)驗(yàn)來開，如果開發(fā)者對(duì)于特定系統(tǒng)行為寫出多行實(shí)現(xiàn)概要，業(yè)務(wù)人員會(huì)感到不耐煩，他們會(huì)覺得這是浪費(fèi)他們的時(shí)間并不耐煩的急于闡釋他們假想的下一個(gè)系統(tǒng)行為。

現(xiàn)在我們從另一個(gè)角度看：使用TDD方法，并且寫出測試概要：

//創(chuàng)建支票后，過期日期=創(chuàng)建日期+20天
it "after_create an Invoice sets a reminder date to be creation + 20 business days"
//Account#primary_payment_contact返回支付聯(lián)系人或者用戶項(xiàng)目管理者
it "Account#primary_payment_contact returns the current payment contact or the client project manager"
//InvoiceChecker#mailer 檢查是否過期，如果是，就發(fā)郵件提醒。
it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

這些測試是有用的，不過只是對(duì)一些人有用：工程師。BDD是用來溝通（交叉功能）項(xiàng)目成員的工具，包括開發(fā)者和業(yè)務(wù)人員。

通過暫時(shí)掛起（不實(shí)現(xiàn)）具體行為，你可以進(jìn)行測試優(yōu)先的開發(fā)。首先，編寫測試；接著，運(yùn)行測試（當(dāng)然是運(yùn)行失敗的，因?yàn)槲覀兌歼€沒開始實(shí)現(xiàn)具體行為）；編寫行為，使他能跑；修正，使他能正確運(yùn)行。

BDD社區(qū)的很多工作和產(chǎn)品都使得測試中的斷言檢查讀起來向普通語言一樣。下面是一個(gè)刻板老套的RSpec測試：

a = 42
a.should == 42

這個(gè)格式使得結(jié)果易于閱讀和理解。但注意這不是我們?cè)诖怂鶓?yīng)該做的，我們應(yīng)該盡快獲取系統(tǒng)行為的準(zhǔn)確描述，并且堅(jiān)持“每個(gè)系統(tǒng)行為都要測試”的原則。而從之前白板上畫框框的工作，我們基本能夠知道系統(tǒng)行為是什么。

BDD不是修正編碼的奇特方式，它只是用來讓團(tuán)隊(duì)成員（包含業(yè)務(wù)人員、顧客）對(duì)系統(tǒng)行為進(jìn)行溝通而已。

再回看剛才的例子：企業(yè)會(huì)計(jì)系統(tǒng)。

你和業(yè)務(wù)人員討論項(xiàng)目的功能：你（開發(fā)者）從內(nèi)部（各模塊是如何協(xié)作的）分析系統(tǒng)，而他們（業(yè)務(wù)人員）就從外部分析。

你會(huì)思考一些情況并且并對(duì)系統(tǒng)分析師（業(yè)務(wù)人員）就一下情況進(jìn)行提問：

//默認(rèn)的提醒日期是？在支票到期前的第幾天提醒？
* What"s the default reminder date going to be? How many days before the invoice due date?
//這些天數(shù)是指自然日還是工作日？
* Are those business days or just calendar days?
//如果這些支票所屬的賬號(hào)主沒有對(duì)應(yīng)的聯(lián)系方式，那該怎么辦？
* What happens if there"s not a primary contact associated with the account?

因此，使得業(yè)務(wù)人員理解你的問題是非常重要的，因?yàn)樗麄兛赡軐?duì)具體開發(fā)缺乏相應(yīng)的知識(shí)。

有時(shí)候，BDD是一種有益于兩個(gè)部門（如策劃和開發(fā)）協(xié)作和溝通的工具，也是清晰劃分系統(tǒng)功能界限和對(duì)開發(fā)團(tuán)隊(duì)(如預(yù)計(jì)開發(fā)時(shí)間)有更好估計(jì)的一種方法。
可能你意識(shí)到無法從給定日期計(jì)算10天以后的日期（因?yàn)槊總€(gè)月的天數(shù)都不一樣），那么你就需要實(shí)現(xiàn)這個(gè)計(jì)數(shù)功能，而業(yè)務(wù)人員對(duì)這個(gè)計(jì)數(shù)功能可能并不關(guān)心。

開發(fā)者有對(duì)于具體開發(fā)的思考（比如你說的‘天’是什么），業(yè)務(wù)人員也有他們的思考（如：請(qǐng)不要使用’過期’這個(gè)詞語了，有時(shí)候它有不同的意思）。因此，只由一方來考慮系統(tǒng)功能和測試就會(huì)抹殺掉另一方的有價(jià)值的觀點(diǎn)。

當(dāng)然如果業(yè)務(wù)人員或者客戶不能和開發(fā)者共處一室的時(shí)候，讓他們將期望的系統(tǒng)行為和開發(fā)者自己的分析、理解寫在紙上也是一個(gè)有效的溝通方法。