Feb. 24 08:10:25
▲順序很重要啊
想到新劇情
開發人員A：關於之前開發票的那兩個劇情，我想到一個問題。
開發人員B：什麼問題？
開發人員A：這兩個劇情分別表示用含稅價格開發票或是用未稅價格開發票，如果有人同時輸入含稅價格與未稅價格，我們的系統應該有什麼行為？
開發人員B：我也沒想過這個問題，我們問問Product Owner好了。
開發人員們：PO，有一個關於開三聯發票需求的問題要跟你討論。
Product Owner：請說。
開發人員們：我們之前討論的那兩個劇情分別表示用含稅價格開發票或是用未稅價格開發票，但是如果有人同時輸入含稅價格與未稅價格，我們的系統應該有什麼行為？
Product Owner：嗯，我想想…應該是最後選擇的方式會蓋掉前面的。
開發人員們：你是說如果先輸入含稅價格再輸入未稅價格，最後會採用未稅價格計算方式；反之則是用含稅價格計算方式？
Product Owner：對，沒錯。
開發人員們：我們寫一個新的劇情你看看這樣對不對。
Product Owner：嗯…先提供未稅價格再提供含稅價格，所以最後會用含稅價格的計算方式。沒錯，跑測試看看。
開發人員們：你也知道下一步是要跑測試了，我們看一下結果。
Product Owner：測試通過。
開發人員們：讓我們試下一個劇情，先提供含稅價格再提供未稅價格，最後會用未稅價格的計算方式。
開發人員們：測試結果也通過了。
Product Owner：等一下，如果是用未稅價格的計算方式，測試資料中註解起來的這一個例子應該會失敗。我們現在直接把這一筆資料註解起來跑驗收測試，這樣我們沒辦法確定到底是用含稅價格計算還是用未稅價格計算，因為用這兩種方式計算得到的結果是一樣的，只有在10元的這個例子中會不一樣。
開發人員們：哇，PO你的邏輯好清楚喔，可以來寫程式了XD。
Product Owner：別說笑快試看看。
開發人員們：好，先把不適用的這筆測試資料還原，再跑驗收測試，應該要失敗才對。
開發人員們：結果居然全是綠燈，看來案情並不單純。
***
從BDD到TDD
開發人員A：我想先寫一個單元測試來反映這個bug。
開發人員B：好啊，這是好習慣我們要持續保持。
開發人員A：這個單元測試用來表達InvoiceBuilder會用最後提供的價錢種類來計算發票，第一個狀況會用「10元含稅價格」計算，所以稅金為0。第二個狀況會用「10元未稅價格」計算，所以稅金為1。
開發人員B：依照剛剛驗收測試的結果，這個單元測試的第二個狀況應該會失敗。
開發人員A：沒錯，我們跑看看測試案例就知道了
開發人員B：第二種狀況果然失敗了，和我們想的一樣。現在要修改程式讓這個測試案例可以通過。
開發人員A：還是回頭看看InvoiceBuilder類別中關於開發票的邏輯。
開發人員A：我們之前用條件判斷如果含稅價格是0，就用未稅價格先計算出含稅價格再產生發票。但是現在兩種價格都會設定，所以變成含稅價格永遠不為0，因此計算發票的邏輯都會採用含稅價格來計算。
開發人員B：你分析的沒錯，要怎麼改？
開發人員A：既然只能用一種價格來計算發票，那麼當含稅價格被設定後，應該把未稅價格設為0，反之亦然。
開發人員B：我了解你的意思，讓我們試看看。
開發人員B：單元測試案例也通過了。
開發人員A：現在回頭跑驗收測試，原本不適用的案例應該會失敗才對。
開發人員B：驗收測試失敗了，代表我們的程式行為正確了。可以找PO來看了。
***
從TDD回BDD
開發人員們：PO你看看，剛剛那個驗收測試不適用的例子現在會被找出來了，所以驗收測試失敗。代表我們計算發票的邏輯現在會依據最後提供的是含稅價格還是未稅價格來計算。
Product Owner：好，很好。但是驗收測試失敗怎麼辦？開發人員們：沒關係，這個例子原本就是不適用的例子，把他註解起來就好了。
Product Owner：可是我們原本不就是因為這個例子才找到問題的嗎，把它註解起來這樣子如果以後問題再發生我們不是沒有測試案例可以檢查？
開發人員們：這個規則我們已經寫在單元測試中，以後再發生的話會被單元測試找出來。如果你認為這個規則很重要，我們可以單獨寫一條劇情來表達它。
Product Owner：當含稅或未稅金額是10元的時候，採用哪種方式計算會差1元的稅金，這是一個特殊案例，我覺得要記錄下來。
開發人員們：好，那我們增加一個劇情。
Product Owner：對，這樣沒錯，跑看看驗收測試。
開發人員們：驗收測試過了。
Product Owner：很好。我還想要一個單獨的劇情來表達下面這個狀況。
開發人員們：可是這個案例已經包含在另一個劇情之中了。
Product Owner：這我知道，但是多了這一條我覺得比較清楚，兩個例子含稅價格和未稅價格都是10元，一比較之下就知道先後順序會讓稅金差1元。
開發人員們：好吧，你喜歡的話就多寫這一個劇情。跑一下測試案例，也都通過了。
Product Owner：太好了，可以下班了。
***
結論
- 有時候測試案例通過不表示程式沒有問題，還要確認不該通過的測試案是不是會失敗。如果該失敗的案例卻成功了，這才是問題。
- Scenario Outline可以讓我們指定多筆測試資料，用資料驅動的方式來執行驗收測試。在本文中含稅與未稅價格都是10元的特殊例子雖然已經包含在某個Scenario Outline裡面，但是Product Owner認為這個例子比較特殊，需要單獨寫一條Scenario，因此雖然相同的測試條件重複出現但應該還算是可接受的狀況。當然也可以把這個case從Scenario Outline中剔除，以避免不同的劇情重複表達相同的行為。
***
友藏內心獨白：怎麼開個發票那麼麻煩啊。
沒有留言:
張貼留言