資訊專欄INFORMATION COLUMN
摘要：理想情況下項目的參與人員能根據當前系統行為列表判斷新加入的功能行為是否會破壞現有功能。通過暫時掛起不實現具體行為，你可以進行測試優先的開發。
我們一般將測試放在項目的最后時刻進行，甚至在時間較緊時、預算超支，或者其他原因發生時會放棄測試。
項目的管理者好奇為什么開發者就是不能一開始就明白（需求、設計），而在系統有很多利益相關者并且不同的相關者對系統有不同的看法的時候，開發者（特別是在大型項目中），更容易變得迷糊,使得協商過程像盲人摸象一樣。
每個項目的開始，必然是有一個關于項目行為表現、功能特點的討論會，由客戶或者其他業務人員向開發團隊解釋他們就行想要什么。（苦逼又令人討厭的策劃....）
有時候，這些交互、討論以敏捷開發形式表現；有時是設計文檔，就像去年查理斯-福克斯的博客所說的那樣；有時是由Keynote制作的流程圖或者模型；有時甚至是一個簡單的電話解釋而已。
為什么不進行測試？僅通過這些溝通，開發者一般只是負責構建一個能夠運行的系統而已，而這對于一個開發團隊來說，是遠遠不夠的。這(單純的溝通)對于大型系統的業余開發人員來說尤其困難。
一般存在一個爭議：如果客戶/業務人員一開始就對系統的行為、特征有充分的認知，那么為什么往往要撤銷對這些功能、行為進行測試？
答案可能非常簡單：測試一般被認為是共享資產（對大家都有用的），也不被認為是對項目開發有實際價值的。測試只對工程師有用或者只對特定的一些人有用。
那么如何才能使得測試對大家都有價值呢？僅僅是列出系統的功能特性嗎？當然不是，我們應該使用behavior-driven development (BDD)而不是僅僅是test-driven development (TDD)。
BDD是什么？行為驅動開發應該著眼于你的代碼所要實現的業務行為，即“為什么要編寫這樣的代碼？”它可以很好的支撐項目核心工作流程，特別是對于交叉功能的了解與實現。
敏捷BDD開發有很大的好處。當開發者和敏捷項目主或者業務分析師坐在一起，將大概功能框框（具體如何實現由開發者在框內填寫）寫在白板上：
業務人員指定系統的行為特性
開發者基于他們自己對系統的理解向業務人員提問，同時從開發者角度寫下其他附加的行為。
理想情況下：項目的參與人員能根據當前系統行為列表判斷新加入的功能行為是否會破壞現有功能。
我發現這些簡單的行為給了我一些約束，使得我能像一個開發者一樣思考：這些我已經實現的這些測試能夠將我的實現代碼約束在一個規范之中。而那些功能代碼只需滿足這些約束、規范，就能在協作開發中快速完成。
這種協作方法使得我更加專注于提供給最終用戶的功能特性，而且業務人員可以在旁約束、糾正我對系統行為的理解，而不是系統的具體實現。這就是BDD和TDD的突出區別。
BDD的一個例子情景：你是負責開發企業會計系統的團隊一員，系統使用Rails框架實現。有一天，業務人員問你一個關于提醒模塊的功能：提醒用戶他們正在等待處理的發票。你坐下來和業務人員定義這個功能模塊。
你打開你的文本編輯器/筆記本，開始在上面畫上框框，每個框代表用戶需要的功能行為：
//為每個新支票添加一個提醒日期 it "adds a reminder date when an invoice is created" //當提醒日期到來就發郵件提醒 it "sends an email to the invoice"s account"s primary contact after the reminder date has passed" //如果用戶閱讀了郵件就給用戶打上標記 it "marks that the user has read the email in the invoice"
在開發中專注于系統行為使得測試在驗證你所實現系統行為是否正確中是十分有用的，而不僅僅是編碼正確（沒有bug）。要注意的是，這種分析要用業務語言而不是實現系統所采用的具體開發語言。
你不需要將“發票屬于哪個用戶”描述出來，因為開發團隊之外的人也并不關心這種關系。
有些開發者在討論/開發現場就寫出測試樣例，在系統中調用這些所要測試的方法，設置期望值，如下：
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
這些測試樣例必然是運行失敗的，因為我們還沒有實現設置remind_date的代碼。
失敗的測試我明白開發者為什么會寫失敗樣例測試，但是從業務人員的角度來說，這寫測試對他并無用處。一些業務人員可能會被這些測試細節、實現細節搞迷糊，甚至我學得一些開發知識后就插手開發人員的工作。（數據庫設計、代碼復用）
從我的經驗來開，如果開發者對于特定系統行為寫出多行實現概要，業務人員會感到不耐煩，他們會覺得這是浪費他們的時間并不耐煩的急于闡釋他們假想的下一個系統行為。
BDD和TDD的區別現在我們從另一個角度看：使用TDD方法，并且寫出測試概要：
//創建支票后，過期日期=創建日期+20天 it "after_create an Invoice sets a reminder date to be creation + 20 business days" //Account#primary_payment_contact返回支付聯系人或者用戶項目管理者 it "Account#primary_payment_contact returns the current payment contact or the client project manager" //InvoiceChecker#mailer 檢查是否過期，如果是，就發郵件提醒。 it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"
這些測試是有用的，不過只是對一些人有用：工程師。BDD是用來溝通（交叉功能）項目成員的工具，包括開發者和業務人員。
通過暫時掛起（不實現）具體行為，你可以進行測試優先的開發。首先，編寫測試；接著，運行測試（當然是運行失敗的，因為我們都還沒開始實現具體行為）；編寫行為，使他能跑；修正，使他能正確運行。
BDD社區的很多工作和產品都使得測試中的斷言檢查讀起來向普通語言一樣。下面是一個刻板老套的RSpec測試：
a = 42 a.should == 42
這個格式使得結果易于閱讀和理解。但注意這不是我們在此所應該做的，我們應該盡快獲取系統行為的準確描述，并且堅持“每個系統行為都要測試”的原則。而從之前白板上畫框框的工作，我們基本能夠知道系統行為是什么。
BDD不是修正編碼的奇特方式，它只是用來讓團隊成員（包含業務人員、顧客）對系統行為進行溝通而已。
BDD是關于協作和溝通的再回看剛才的例子：企業會計系統。
你和業務人員討論項目的功能：你（開發者）從內部（各模塊是如何協作的）分析系統，而他們（業務人員）就從外部分析。
你會思考一些情況并且并對系統分析師（業務人員）就一下情況進行提問：
//默認的提醒日期是？在支票到期前的第幾天提醒？ * What"s the default reminder date going to be? How many days before the invoice due date? //這些天數是指自然日還是工作日？ * Are those business days or just calendar days? //如果這些支票所屬的賬號主沒有對應的聯系方式，那該怎么辦？ * What happens if there"s not a primary contact associated with the account?
因此，使得業務人員理解你的問題是非常重要的，因為他們可能對具體開發缺乏相應的知識。
有時候，BDD是一種有益于兩個部門（如策劃和開發）協作和溝通的工具，也是清晰劃分系統功能界限和對開發團隊(如預計開發時間)有更好估計的一種方法。
可能你意識到無法從給定日期計算10天以后的日期（因為每個月的天數都不一樣），那么你就需要實現這個計數功能，而業務人員對這個計數功能可能并不關心。
開發者有對于具體開發的思考（比如你說的‘天’是什么），業務人員也有他們的思考（如：請不要使用’過期’這個詞語了，有時候它有不同的意思）。因此，只由一方來考慮系統功能和測試就會抹殺掉另一方的有價值的觀點。
當然如果業務人員或者客戶不能和開發者共處一室的時候，讓他們將期望的系統行為和開發者自己的分析、理解寫在紙上也是一個有效的溝通方法。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8765.html
摘要：測試驅動開發是一種使用自動化單元測試來推動軟件設計并強制依賴關系解耦的技術。使用這種做法的結果是一套全面的單元測試，可隨時運行，以提供軟件可以正常工作的反饋。 showImg(http://ws1.sinaimg.cn/large/005NRne3gy1g2cmxxl7c5j30nc0c8h1p.jpg); 一、幾種概念（稍微了解一下） ATDD： Acceptance Test Dr...
閱讀 3095·2021-10-13 09:40
閱讀 3945·2021-09-22 15:51
閱讀 1493·2021-09-22 15:48
閱讀 1060·2021-09-06 15:00
閱讀 1790·2019-08-30 15:43
閱讀 2354·2019-08-29 18:35
閱讀 1666·2019-08-29 16:18
閱讀 3612·2019-08-29 12:49
