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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//為每個新支票添加一個提醒日期
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)行為使得測試在驗證你所實現(xiàn)系統(tǒng)行為是否正確中是十分有用的，而不僅僅是編碼正確（沒有bug）。要注意的是，這種分析要用業(yè)務(wù)語言而不是實現(xiàn)系統(tǒng)所采用的具體開發(fā)語言。
你不需要將“發(fā)票屬于哪個用戶”描述出來，因為開發(fā)團(tuán)隊之外的人也并不關(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

這些測試樣例必然是運行失敗的，因為我們還沒有實現(xiàn)設(shè)置remind_date的代碼。

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

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

現(xiàn)在我們從另一個角度看：使用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)系人或者用戶項目管理者
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"

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

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

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

a = 42
a.should == 42

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

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

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

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

你會思考一些情況并且并對系統(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?
//如果這些支票所屬的賬號主沒有對應(yīng)的聯(lián)系方式，那該怎么辦？
* What happens if there"s not a primary contact associated with the account?

因此，使得業(yè)務(wù)人員理解你的問題是非常重要的，因為他們可能對具體開發(fā)缺乏相應(yīng)的知識。

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

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

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