《驗收測試驅動開發：ATDD執行個體詳解》—第1章1.1節代客泊車

本節書摘來自異步社群《驗收測試驅動開發：atdd執行個體詳解》一書中的第1章1.1節代客泊車，作者【德】markus gärtner，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

第一部分 機場停車場

驗收測試驅動開發：atdd執行個體詳解

在這一部分，我們來看一個線上應用。通過gui（圖形使用者界面）對網頁進行自動化測試是目前比較成熟的技術之一，不過這種方法也有缺點。然而無論怎樣，大多數從事線上應用開發的團隊都能從這本書中找到一些如何驅動其測試的線索。

我們要做的是一個國際機場的停車費電腦。這個國際機場中有幾種不同的停車場，而且停車費用随停車時長的不同也有所不同。

停車費電腦的業務規則太複雜，以至于無論團隊怎樣努力，最終可能也無法完成這個線上應用。團隊成員覺得他們以前得到的需求是錯的，是以這次他們決定用不同的方式，他們要和使用者一起在“需求讨論會”裡讨論這個應用。測試人員、開發人員和客戶坐在一起讨論能描述停車費電腦業務規則的各種執行個體（example）。

與程式設計活動同時進行的是，測試人員使用ruby、cucumber配合selenium将這些執行個體自動化。在某些時刻他可能需要開發人員的幫助，在介紹裡我們就不詳述了。

你想知道測試人員tony用什麼工具編輯cucumber的測試用例嗎？當然是emacs，不是vi。1

1使用emacs的unix開發人員往往覺得使用vi的開發人員守舊。——譯者注

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。

第1章　停車費電腦讨論會

不久前，major國際航空公司決定擴充其在網際網路上的服務。具體而言，他們想讓自己的網站為潛在旅客提供預先計算停車費的功能。旅客隻要通過送出一個線上表單，系統就可以按其停車時長來計算停車費用。

以前major國際航空公司做過這樣一個表單，但旅客的回報非常差。是以管理團隊決定再重新做一個。

總結前面項目失敗的經驗教訓，項目團隊（包括資深開發人員phyllis、開發人員alex和測試人員tony）決定采取一種新的方式。

上次做的時候，項目需求從頭到尾一直在變，導緻代碼也是一個更新檔接着一個更新檔，最後發現一開始實作的東西就是錯的。他們不想再重複這個過程。是以，這次團隊要采用“需求讨論會”的方式來更好地收集停車費電腦的業務規則。為此，phyllis和tony特别邀請了major國際航空公司停車場管理部門的經理bill參加讨論會，bill是停車費用的業務專家。

1.1　代客泊車

phyllis： 好吧，那我們讨論一下停車費電腦的需求。bill，你能講一下嗎？

bill： 我們基本上有3種不同的停車位。有些是按小時計費，有些按天計費，有些設有每日或每周的收費上限。

phyllis： 這3種不同的停車位具體指什麼？它們有名字嗎？

bill： 代客泊車、臨時停車位和正常車位。如果丢失發票，會被加收10塊錢。

phyllis： 讓我們集中看這3種類型。它們的差別是什麼？

bill： 對于代客泊車，客人把車放在代客泊車區，得到一張取車的憑據。

phyllis： 能講一下停車費用嗎？

bill： 代客泊車每天18美元，5小時以内（含5小時）優惠6美元。

phyllis： 等一下，bill。你的意思是即使30分鐘我也要交12塊錢，3個小時也是一樣，5小時也是？但如果是5小時零1分鐘，我就不得不交18美元，和12小時或24小時一樣？

bill： 是的，完全正确。

phyllis： 那24小時零1分鐘呢？是30美元還是36美元？

bill： 哦，那當然是36美元了。

phyllis： 那每周上限呢？代客泊車有嗎？

bill： 沒有，這基本就是代客泊車的全部了。

tony： 好，那讓我把它們寫下來作為執行個體。

tony把讨論的執行個體記在表1-1中 ，标記為“代客泊車”。

phyllis： 這些執行個體對“代客泊車”有意義嗎？

bill： 是的，這些執行個體概括了我們的談話的内容。