在 上一篇文章 中我已經解釋了為什么把所有編程問題當作一群喪尸一次性處理是錯誤的。我也解釋了 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）

在上一篇文章中，通過應用了最簡場景，你在代碼里構建了一條最簡可行通路。這個代碼里沒有任何業務處理邏輯。現在是時候向系統中添加一個元素了。

最簡場景表示系統中什么也沒有，這是一個空的用例，我們什么也不用關心。單元素場景代表我們有一個元素需要關心考慮。這個單一元素可能是集合中的一個元素、一個訪問著或者一個需要處理的事件。

對于多元素場景，我們需要處理更復雜的情況，比如兩個或更多的集合元素或事件。

單元素場景

在上一篇文章的代碼基礎上，向虛擬購物筐里添加一些商品。首先，寫一個偽測試：

[Fact]
public void Add1ItemBasketHas1Item() {
        var expectedNoOfItems = 1;
        var actualNoOfItems = 0;
        Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

不出所料，這個測試失敗了，因為硬編碼了一個錯誤的值：

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.57] tests.UnitTest1.NewlyCreatedBasketHas0Items [FAIL]
  X tests.UnitTest1.NewlyCreatedBasketHas0Items [4ms]
  Error Message:
   Assert.Equal() Failure
Expected: 0
Actual: 1
[...]

現在是時候停止偽造了。現在你已經用 ArrayList 實現了購物筐。那么應該怎么實現商品呢？

簡潔性應該一直是你的指導原則。在不了解商品的太多信息的情況下，你可以先用另一個集合來實現它。這個表示商品的集合應該包含些什么呢？由于你多半會關心計算購物筐中的商品總價，所以對商品的表示至少需要包含價格（可以是任意貨幣，為簡單起見，不妨假設是人民幣）。

（我們需要）一個簡單的集合類型，它包含一個商品 ID（可以在系統中的其它地方使用 ID 來指向該商品）和這個商品的價格。

鍵值對類型的數據結構可以很容易滿足這個需求。在 C# 中最先被想到的數據結構就是 Hashtable。

在購物應用的代碼中給 IShoppingAPI 增加一個新功能：

int AddItem(Hashtable item);

這個新功能以一個用 Hashtable 表示的商品為輸入，返回購物筐中的商品數量。

將測試代碼中硬編碼的值提替換為對接口的調用：

[Fact]
public void Add1ItemBasketHas1Item() {            
    var expectedNoOfItems = 1;
    Hashtable item = [new][3] Hashtable();
    var actualNoOfItems = shoppingAPI.AddItem(item);
    Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

在上面的代碼中實例化了一個 Hashtable 并命名為 item，然后調用購物接口中的 AddItem(item) 方法，該方法會返回購物筐中實際的商品數量。

轉到 ShoppingAPI 類中，實現這個方法：

public int AddItem(Hashtable item) {
    return 0;
}

這里再次通過寫假代碼來檢驗測試的效果（測試是業務代碼的第一個調用者）。如果測試失敗，將硬編碼值換成實際的代碼：

public int AddItem(Hashtable item) {
    basket.Add(item);
    return basket.Count;
}

在上面的代碼中，向購物筐里添加了一件商品，然后返回購物筐中的商品數量：

Test Run Successful.
Total tests: 2
     Passed: 2
 Total time: 1.0633 Seconds

到目前為止，你通過了兩個測試，同時也基本里解了 ZOMBIES 方法中的最簡場景和單元素場景兩部分。

反思總結

回顧前面所做的工作，你會發現通過將注意力集中到處理最簡場景和單元素場景上，你在構建接口的同時也定義了一些業務邏輯邊界！這不是很棒嗎？現在你已經部分地實現了最關鍵的抽象邏輯，并且能夠處理什么也沒有和只有一個元素的的情況。因為你正在構建的是一個電子交易 API，所以你不能對顧客的購物行為預設其它限制。總而言之，虛擬購物筐應該是無限大的。

ZOMBIES 提供的逐步優化思路的另一個重要方面（雖然不是很明顯）是從大概思路到具體實現的阻力。你也許已經注意到了，要具體實現某個東西總是困難重重。倒不如先用硬編碼值來構造一個偽實現。只有看到接口與測試之間以一種合理的方式交互之后，你才會愿意開始完善實現代碼。

即便如此，你也應該采用簡單直接的代碼結構，盡可能避免條件邏輯分支。

多元素場景

通過定義顧客向購物筐里添加兩件商品時的期望來拓展應用程序。首先構造一個偽測試。它的期望值為 2，但是現在將實際值硬編碼為 0，強制讓測試失敗：

[Fact]
public void Add2ItemsBasketHas2Items() {
        var expectedNoOfItems = 2;
        var actualNoOfItems = 0;
        Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

執行測試，前兩個測試用例通過了（針對最簡場景和單元素場景的測試），而硬編碼的測試不出所料地失敗了：

A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.57] tests.UnitTest1.Add2ItemsBasketHas2Items [FAIL]
  X tests.UnitTest1.Add2ItemsBasketHas2Items [2ms]
  Error Message:
   Assert.Equal() Failure
Expected: 2
Actual: 0

Test Run Failed.
Tatal tests: 3
     Passed: 2
     Failed: 1

將硬編碼值替換為實際的代碼調用：

[Fact]
public void Add2ItemsBasketHas2Items() {
        var expectedNoOfItems = 2;
        Hashtable item = [new][3] Hashtable();
        shoppingAPI.AddItem(item);
        var actualNoOfItems = shoppingAPI.AddItem(item);
        Assert.Equal(expectedNoOfItems, actualNoOfItems);
}

在這個測試中，你向購物筐中添加了兩件商品（實際上是將同一件商品添加了兩次），然后比較期望的商品數量和第二次添加商品后調用 shoppingAPI 返回的商品數量是否相等。

現在所有測試都能夠通過！

敬請期待

現在你已經了解了最簡場景、單元素場景和多元素場景。我將下一篇文章中介紹邊界行為和接口定義。敬請期待!