ZOMBIES：在軟件開發中定義邊界和接口（三）
喪尸沒有邊界感。它們踩倒柵欄，推倒圍墻，進入不屬于它們的地盤。在前面的文章中，我已經解釋了為什么把所有編程問題當作一群喪尸一次性處理是錯誤的。
ZOMBIES 代表首字母縮寫：
- Z – 最簡場景（Zero）
- O – 單個元素場景（One）
- M – 多個元素場景（Many or more complex）
- B – 邊界行為（Boundary behaviors）
- I – 接口定義（Interface definition）
- E – 處理特殊行為（Exercise exceptional behavior）
- S – 簡單場景用簡單的解決方案（Simple scenarios, simple solutions）
在本系列的前面兩篇文章中，我演示了 ZOMBIES 方法的前三部分：最簡場景、單元素場景和多元素場景。第一篇文章 實現了最簡場景，它提供了代碼中的最簡可行路徑。第二篇文章中針對單元素場景和多元素場景 運行測試。在這篇文章中，我將帶你了解邊界和接口。
回到單元素場景
要想處理邊界，你需要繞回來（迭代）。
首先思考下面的問題：電子商務的邊界是什么？我需要限制購物框的大小嗎？（事實上，我不認為這有任何意義。）
目前唯一合理的邊界條件是確保購物框里的商品數量不能為負數。將這個限制表示成可運行的期望：
[Fact]
public void Add1ItemRemoveItemRemoveAgainHas0Items() {
var expectedNoOfItems = 0;
var actualNoOfItems = -1;
Assert.Equal(expectedNoOfItems, actualNoOfItems);
}這就是說，如果你向購物框里添加一件商品，然后將這個商品移除兩次，shoppingAPI 的實例應該告訴你購物框里有零個商品。
當然這個可運行期望（微測試）不出意料地會失敗。想要這個微測試能夠通過，最小改動是什么呢？
[Fact]
public void Add1ItemRemoveItemRemoveAgainHas0Items() {
var expectedNoOfItems = 0;
Hashtable item = new Hashtable();
shoppingAPI.AddItem(item);
shoppingAPI.RemoveItem(item);
var actualNoOfItems = shoppingAPI.RemoveItem(item);
Assert.Equal(expectedNoOfItems, actualNoOfItems);
}這個期望測試依賴于 RemoveItem(item) 功能。目前的 shippingAPI 還不具備該功能，你需要增加該功能。
回到 app 文件夾，打開 IShippingAPI.cs 文件，新增以下聲明：
int RemoveItem(Hashtable item);到 ShippingAPI.cs 中實現該功能：
public int RemoveItem(Hashtable item) {
basket.RemoveAt(basket.IndexOf(item));
return basket.Count;
}運行，然后你會得到如下錯誤：
Error
系統在移除一個不在購物框的商品，這導致了系統崩潰。加一點點 防御式編程defensive programming：
public int RemoveItem(Hashtable item) {
if(basket.IndexOf(item) >= 0) {
basket.RemoveAt(basket.IndexOf(item));
}
return basket.Count;
}在移除商品之前先檢查它是否在購物框中。（你可能試過用捕獲異常的方式來處理，但是我認為上面的處理方式更具可讀性。）
更多具體的期望
在講更多具體的期望之前，讓我們先探討一下什么是接口。在軟件工程中，接口表示一種規范，或者對能力的描述。從某種程度上來說，接口類似于菜譜。它羅列出了制作蛋糕的原材料，但它本身并不能吃。我們只是按照菜譜上的說明來烤蛋糕。
與此類似，我們首先通過說明這個服務能做什么的方式來定義我們的服務。這個描述說明就是所謂的接口。但是接口本身并不能向我們提供任何功能。它只是指導我們實現指定功能的藍圖而已。
到目前為止，我們已經實現了接口（只是某部分實現了，稍后還會增加新功能）和業務處理邊界（也就是購物框里的商品不能是負數）。你指導了 shoppingAPI 怎么向購物框添加商品，并通過 Add2ItemsBasketHas2Items 測試驗證了該功能的有效性。
然而僅僅具備向購物框添加商品的功能還不足以使其成為一個網購應用程序。它還需要能夠計算購物框里的商品的總價。現在需要增加另一個期望。
按照慣例，從最直接明了的期望開始。當你向購物框里加入一件價值 ￥10 的商品時，你希望這個購物 API 能正確地計算出總價為 ￥10。
第五個測試（偽造版）如下：
[Fact]
public void Add1ItemPrice10GrandTotal10() {
var expectedTotal = 10.00;
var actualTotal = 0.00;
Assert.Equal(expectedTotal, actualTotal);
}還是一樣的老把戲，通過硬編碼一個錯誤的值讓 Add1ItemPrice10GrandTotal10 測試失敗。當然前三個測試成功通過，但第四個新增的測試失敗了：
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.57] tests.UnitTest1.Add1ItemPrice10GrandTotal10 [FAIL]
X tests.UnitTest1.Add1ItemPrice10GrandTotal10 [4ms]
Error Message:
Assert.Equal() Failure
Expected: 10
Actual: 0
Test Run Failed.
Total tests: 4
Passed: 3
Failed: 1
Total time: 1.0320 Seconds將硬編碼值換成實際的處理代碼。首先，檢查接口是否具備計算訂單總價的功能。根本沒有這種東西。目前為止接口中只聲明了三個功能：
int NoOfItems();int AddItem(Hashtable item);int RemoveItem(Hashtable item);
它們都不具備計算總價的能力。所以需要聲明一個新功能：
double CalculateGrandTotal();這個新功能應該讓 shoppingAPI 具備計算總價的能力。這是通過遍歷購物框中的商品并把它們的價格累加起來實現的。
修改第五個測試：
[Fact]
public void Add1ItemPrice10GrandTotal10() {
var expectedGrandTotal = 10.00;
Hashtable item = new Hashtable();
item.Add("00000001", 10.00);
shoppingAPI.AddItem(item);
var actualGrandTotal = shoppingAPI.CalculateGrandTotal();
Assert.Equal(expectedGrandTotal, actualGrandTotal);
}這個測試表明了這樣的期望：如果向購物框里加入一件價格 ￥10 的商品，然后調用 CalculateGrandTotal() 方法，它會返回商品總價 ￥10。這是一個完全合理的期望，它完全符合商品總價計算的邏輯。
那么怎么實現這個功能呢？就像以前一樣，先寫一個假的實現。回到 ShippingAPI 類中，實現在接口中聲明的 CalculateGrandTotal() 方法：
public double CalculateGrandTotal() {
return 0.00;
}現在先將返回值硬編碼為 0.00，只是為了檢驗這個測試能否正常運行，并確認它是能夠失敗的。事實上，它能夠運行，并且如預期一樣失敗。接下來的工作就是正確實現計算商品總價的處理邏輯：
public double CalculateGrandTotal() {
double grandTotal = 0.00;
foreach(var product in basket) {
Hashtable item = product as Hashtable;
foreach(var value in item.Values) {
grandTotal += Double.Parse(value.ToString());
}
}
return grandTotal;
}運行，五個測試全部通過！
從單元素場景到多元素場景
現在是時候進入下一輪迭代了。你已經通過處理最簡場景、單元素場景和邊界場景迭代地構建了系統，現在需要處理稍復雜的多元素場景了。
快捷提示：由于我們一直在針對單個元素場景、多元素場景和邊界行為這三點上對軟件進行迭代改進，一些讀者可能會認為我們同樣應該對接口進行改進。我們稍后就會發現，接口已經完全滿足需要了，目前沒有新增功能的必要。請記住，應該保持接口的簡潔。（盲目地）擴增接口不會帶來任何好處，只會引入噪音。我們要遵循 奧卡姆剃刀Occam's Razor 原則：如無必要，勿增實體。 現在我們已經基本完成了接口功能描述的工作，是時候改進實現了。
通過上一輪的迭代，系統已經能夠處理購物框里有超過一件商品的情況了。現在我么來讓系統具備購物框里有超過一件商品時計算總價的能力。首先寫可執行期望：
[Fact]
public void Add2ItemsGrandTotal30() {
var expectedGrandTotal = 30.00;
var actualGrandTotal = 0.00;
Assert.Equal(expectedGrandTotal, actualGrandTotal);
}硬編碼所有值，盡量讓期望測試失敗。
測試確實失敗了，現在得想辦法讓它通過。向購物框添加兩件商品，然后調用 CalculateGrandTotal() 方法：
[Fact]
public void Add2ItemsGrandTotal30() {
var expectedGrandTotal = 30.00;
Hashtable item = new Hashtable();
item.Add("00000001", 10.00);
shoppingAPI.AddItem(item);
Hashtable item2 = new Hashtable();
item2.Add("00000002", 20.00);
shoppingAPI.AddItem(item2);
var actualGrandTotal = shoppingAPI.CalculateGrandTotal();
Assert.Equal(expectedGrandTotal, actualGrandTotal);
}測試通過。現在共有六個可以通過的微測試，系統回到了穩態。
設定期望
作為一個認真負責的工程師，你希望確保當用戶向購物框添加一些商品然后又移除一些商品后系統仍然能夠計算出正確出總價。下面是這個新的期望：
[Fact]
public void Add2ItemsRemoveFirstItemGrandTotal200() {
var expectedGrandTotal = 200.00;
var actualGrandTotal = 0.00;
Assert.Equal(expectedGrandTotal, actualGrandTotal);
}這個期望表示將兩件商品加入到購物框，然后移除第一件后期望的總價是 ￥200。硬編碼行為失敗了。現在設計更具體的正面測試樣例，然后運行代碼：
[Fact]
public void Add2ItemsRemoveFirstItemGrandTotal200() {
var expectedGrandTotal = 200.00;
Hashtable item = new Hashtable();
item.Add("00000001", 100.00);
shoppingAPI.AddItem(item);
Hashtable item2 = new Hashtable();
item2.Add("00000002", 200.00);
shoppingAPI.AddItem(item2);
shoppingAPI.RemoveItem(item);
var actualGrandTotal = shoppingAPI.CalculateGrandTotal();
Assert.Equal(expectedGrandTotal, actualGrandTotal);
}在這個正面測試樣例中，先向購物框加入第一件商品（編號為 00000001，價格為 ￥100），再加入第二件商品（編號為 00000002，價格為 ￥200）。然后將第一件商品移除，計算總價，比較計算值與期望值是否相等。
運行期望測試，系統正確地計算出了總價，滿足這個期望測試。現在有七個能順利通過的測試了。系統運行良好，無異常！
Test Run Successful.
Total tests: 7
Passed: 7
Total time: 0.9544 Seconds敬請期待
現在你已經學習了 ZOMBIES 方法中的 ZOMBI 部分，下一篇文章將介紹處理特殊行為。到那個時候，你可以試試自己的測試！
