在 上一篇文章 中我已經(jīng)解釋了為什么把所有編程問題當(dāng)作一群喪尸一次性處理是錯(cuò)誤的。我也解釋了 ZOMBIES 方法中的第一條：最簡場景。本文中我將進(jìn)一步介紹接下來的兩條：單元素場景和多元素場景。

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）

在上一篇文章中，通過應(yīng)用了最簡場景，你在代碼里構(gòu)建了一條最簡可行通路。這個(gè)代碼里沒有任何業(yè)務(wù)處理邏輯?，F(xiàn)在是時(shí)候向系統(tǒng)中添加一個(gè)元素了。

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

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

單元素場景

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

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

不出所料，這個(gè)測試失敗了，因?yàn)橛簿幋a了一個(gè)錯(cuò)誤的值：

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
[...]

現(xiàn)在是時(shí)候停止偽造了?，F(xiàn)在你已經(jīng)用 ArrayList 實(shí)現(xiàn)了購物筐。那么應(yīng)該怎么實(shí)現(xiàn)商品呢？

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

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

鍵值對類型的數(shù)據(jù)結(jié)構(gòu)可以很容易滿足這個(gè)需求。在 C# 中最先被想到的數(shù)據(jù)結(jié)構(gòu)就是 Hashtable。

在購物應(yīng)用的代碼中給 IShoppingAPI 增加一個(gè)新功能：

int AddItem(Hashtable item);

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

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

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

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

轉(zhuǎn)到 ShoppingAPI 類中，實(shí)現(xiàn)這個(gè)方法：

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

這里再次通過寫假代碼來檢驗(yàn)測試的效果（測試是業(yè)務(wù)代碼的第一個(gè)調(diào)用者）。如果測試失敗，將硬編碼值換成實(shí)際的代碼：

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

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

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

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

反思總結(jié)

回顧前面所做的工作，你會(huì)發(fā)現(xiàn)通過將注意力集中到處理最簡場景和單元素場景上，你在構(gòu)建接口的同時(shí)也定義了一些業(yè)務(wù)邏輯邊界！這不是很棒嗎？現(xiàn)在你已經(jīng)部分地實(shí)現(xiàn)了最關(guān)鍵的抽象邏輯，并且能夠處理什么也沒有和只有一個(gè)元素的的情況。因?yàn)槟阏跇?gòu)建的是一個(gè)電子交易 API，所以你不能對顧客的購物行為預(yù)設(shè)其它限制?？偠灾?，虛擬購物筐應(yīng)該是無限大的。

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

即便如此，你也應(yīng)該采用簡單直接的代碼結(jié)構(gòu)，盡可能避免條件邏輯分支。

多元素場景

通過定義顧客向購物筐里添加兩件商品時(shí)的期望來拓展應(yīng)用程序。首先構(gòu)造一個(gè)偽測試。它的期望值為 2，但是現(xiàn)在將實(shí)際值硬編碼為 0，強(qiáng)制讓測試失?。?/p>

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

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

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

將硬編碼值替換為實(shí)際的代碼調(diào)用：

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

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

現(xiàn)在所有測試都能夠通過！

敬請期待

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