8

BDD(8):實作第一個開發票Scenario

 2 years ago
source link: http://teddy-chen-tw.blogspot.com/2017/02/bdd8scenario.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

BDD(8):實作第一個開發票Scenario

Feb. 22 07:15~09:40

▲本集範例Scenario

Step 1

▼關於Cucumber的基本知識介紹得差不多了,可以開始實作開三聯發票的第一個Scenario。這個Scenario一共有5個step(步驟),首先看到第一個步驟:「Given The VAT rate is 5%」,一開始step definition的實作想法很單純,新增一個Invoice物件,把營業稅5%記錄在它身上。昨天已經介紹過用Percentage類別來支援營業稅用5%或0.05的表示方式,以下的程式碼紅色部分表示語法錯誤,因為Invoice類別和它身上的setVATRate函數都還沒定義。我們眼下的目標就是讓這個step definition至少沒有語法錯誤。

▼實作Invoice類別和setVATRate函數。

▼實作完成之後執行測試案例,第一個步驟通過。之後的例子實作完成之後都會執行測試案例,除非特別狀況否則執行結果畫面就不重複擷取。

Step 2

▼第二個步驟:「And the tax included price is 17000」, 把含稅價格設給Invoice物件,當然Invoice身上沒有setTaxIncludedPrice函數所以出現紅色語法錯誤。

▼在Invoice類別加上setTaxIncludedPrice函數實作。

Step 3

▼到目前為止都很簡單,鄉民們可能看到快睡著了。請不要轉台,問題即將出現在第三個步驟:「When  I issue a company invoice」, 開一張發票。這個步驟說要開一張發票,但是Invoice物件已經存在了,顯然之前那兩個步驟的實作似乎沒有反映需求

▼第三步驟也許應該長成下面這個樣子,透過另一個InvoiceBuilder類別來開一張發票。

▼回頭修改前兩個步驟,step definition變成下面這樣。

▼接下來先新增InvoiceBuilder類別,然後套用move method重構把setVATRate和setTaxIncludedPrice移到它身上。

▼issue函數回傳Invoice物件,並設定Invoice物件擁有含稅價格、營業稅率、營業稅金、未稅價格。getVAT函數用來計算稅金,getTaxExcludedPrice函數用來計算未稅價格,目前都還沒實作。

▼getVAT和getTaxExcludedPrice實作完成之後發現Invoice少了合適的建構函數。

▼實作Invoice的建構函數。

▼跑測試案例,現在前三個步驟都通過了。

Step 4

▼「Then I should see the VAT is 810」告訴我們發票的稅金應該是810。

▼在Invoice物件身上實作getVAT函數,

▼執行測試案例也通過了。

Step 5

▼最後一個步驟「And the tax excluded price is 16190」。

▼在Invoice物件身上實作getTaxExcludedPrice函數,

▼執行測試案例也通過了。Scenario所包含的5個步驟都通過,整個Scenario也就變成綠燈了。

討論

  • 看到這裡鄉民們對於BDD—行為驅動開發—應該很有軟體開發「被行為推著走(驅動)」的感覺吧。藉由例子定義行為,然後逐一將例子中所規範的行為透過step definition轉成程式實作。其實這也不是什麼新觀念,和20幾年前的RUP強調use case driven的感覺很像,只不過use case的粒度比起一個scenario大很多,用精實開發的術語來說算是「大批量生產」。BDD或Specification by Example的一個例子粒度很小,算是「小批量生產」,這也是精實開發所鼓勵的方式。當然兩者背後的實作細節差異頗大,不過大方向來看都是藉由「行為」來驅動系統的開發步調(use case也是一種定義系統行為的方式)。
  • 另外,這個例子的「商業流程很簡單(幾乎沒有)」,所以鄉民們在step definition看不到什麼商業流程的描述。實做這些step definition的物件也很簡單,也沒什麼複雜的程式邏輯,所以BDD要銜接到TDD的部分在這個例子也看不到。換句話說,還不需要撰寫單元測試來弄清楚InvoiceBuilder與Invoice的行為,因為這兩個類別的行為目前透過step definition已經可以表達清楚了。
屏幕截图 2017-02-22 09.29.55
  • Domain Model目前只有兩個類別,是由BDD的過程所探討出來的,而不是採用傳統OOAD方式先找類別、屬性、方法、關係,然後撰寫程式實作。
  • 程式目前還沒重構,可以思考看看有沒有需要重構的地方。

友藏內心獨白:這系列的目標快變成從小例子學BDD+TDD+DDD。

延伸閱讀


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK