[[280217]]

基于 .NET 的 xUnit.net 測(cè)試框架，開發(fā)一款自動(dòng)貓門的邏輯，讓門在白天開放，夜間鎖定。

在本系列的第一篇文章中，我演示了如何使用設(shè)計(jì)的故障來確保代碼中的預(yù)期結(jié)果。在第二篇文章中，我將繼續(xù)開發(fā)示例項(xiàng)目：一款自動(dòng)貓門，該門在白天開放，夜間鎖定。

在此提醒一下，你可以按照此處的說明使用 .NET 的 xUnit.net 測(cè)試框架。

關(guān)于白天時(shí)間

回想一下，測(cè)試驅(qū)動(dòng)開發(fā)（TDD）圍繞著大量的單元測(cè)試。

第一篇文章中實(shí)現(xiàn)了滿足 Given7pmReturnNighttime 單元測(cè)試期望的邏輯。但還沒有完，現(xiàn)在，你需要描述當(dāng)前時(shí)間大于 7 點(diǎn)時(shí)期望發(fā)生的結(jié)果。這是新的單元測(cè)試，稱為 Given7amReturnDaylight：

       [Fact]
       public void Given7amReturnDaylight()
       {
           var expected = "Daylight";
           var actual = dayOrNightUtility.GetDayOrNight();
           Assert.Equal(expected, actual);
       }

現(xiàn)在，新的單元測(cè)試失敗了（越早失敗越好?。?/p>

Starting test execution, please wait...
[Xunit.net 00:00:01.23] unittest.UnitTest1.Given7amReturnDaylight [FAIL]
Failed unittest.UnitTest1.Given7amReturnDaylight
[...]

期望接收到字符串值是 Daylight，但實(shí)際接收到的值是 Nighttime。

分析失敗的測(cè)試用例

經(jīng)過仔細(xì)檢查，代碼本身似乎已經(jīng)出現(xiàn)問題。 事實(shí)證明，GetDayOrNight 方法的實(shí)現(xiàn)是不可測(cè)試的！

看看我們面臨的核心挑戰(zhàn)：

1. GetDayOrNight 依賴隱藏輸入。

   dayOrNight 的值取決于隱藏輸入（它從內(nèi)置系統(tǒng)時(shí)鐘中獲取一天的時(shí)間值）。

2. GetDayOrNight 包含非確定性行為。

   從系統(tǒng)時(shí)鐘中獲取到的時(shí)間值是不確定的。（因?yàn)椋┰摃r(shí)間取決于你運(yùn)行代碼的時(shí)間點(diǎn)，而這一點(diǎn)我們認(rèn)為這是不可預(yù)測(cè)的。

3. GetDayOrNight API 的質(zhì)量差。

   該 API 與具體的數(shù)據(jù)源（系統(tǒng) DateTime）緊密耦合。

4. GetDayOrNight 違反了單一責(zé)任原則。

   該方法實(shí)現(xiàn)同時(shí)使用和處理信息。優(yōu)良作法是一種方法應(yīng)負(fù)責(zé)執(zhí)行一項(xiàng)職責(zé)。

5. GetDayOrNight 有多個(gè)更改原因。

   可以想象內(nèi)部時(shí)間源可能會(huì)更改的情況。同樣，很容易想象處理邏輯也將改變。這些變化的不同原因必須相互隔離。

6. 當(dāng)（我們）嘗試了解 GetDayOrNight 行為時(shí)，會(huì)發(fā)現(xiàn)它的 API 簽名不足。

   最理想的做法就是通過簡單的查看 API 的簽名，就能了解 API 預(yù)期的行為類型。

7. GetDayOrNight 取決于全局共享可變狀態(tài)。

   要不惜一切代價(jià)避免共享的可變狀態(tài)！

8. 即使在閱讀源代碼之后，也無法預(yù)測(cè) GetDayOrNight 方法的行為。

   這是一個(gè)嚴(yán)重的問題。通過閱讀源代碼，應(yīng)該始終非常清晰，系統(tǒng)一旦開始運(yùn)行，便可以預(yù)測(cè)出其行為。

失敗背后的原則

每當(dāng)你遇到工程問題時(shí)，建議使用久經(jīng)考驗(yàn)的分而治之divide and conquer策略。在這種情況下，遵循關(guān)注點(diǎn)分離separation of concerns的原則是一種可行的方法。

關(guān)注點(diǎn)分離（SoC）是一種用于將計(jì)算機(jī)程序分為不同模塊的設(shè)計(jì)原理，以便每個(gè)模塊都可以解決一個(gè)關(guān)注點(diǎn)。關(guān)注點(diǎn)是影響計(jì)算機(jī)程序代碼的一組信息。關(guān)注點(diǎn)可以和要優(yōu)化代碼的硬件的細(xì)節(jié)一樣概括，也可以和要實(shí)例化的類的名稱一樣具體。完美體現(xiàn) SoC 的程序稱為模塊化程序。

（出處）

GetDayOrNight 方法應(yīng)僅與確定日期和時(shí)間值表示白天還是夜晚有關(guān)。它不應(yīng)該與尋找該值的來源有關(guān)。該問題應(yīng)留給調(diào)用客戶端。

必須將這個(gè)問題留給調(diào)用客戶端，以獲取當(dāng)前時(shí)間。這種方法符合另一個(gè)有價(jià)值的工程原理——控制反轉(zhuǎn)inversion of control。Martin Fowler 在這里詳細(xì)探討了這一概念。

框架的一個(gè)重要特征是用戶定義的用于定制框架的方法通常來自于框架本身，而不是從用戶的應(yīng)用程序代碼調(diào)用來的。該框架通常在協(xié)調(diào)和排序應(yīng)用程序活動(dòng)中扮演主程序的角色。控制權(quán)的這種反轉(zhuǎn)使框架有能力充當(dāng)可擴(kuò)展的框架。用戶提供的方法為框架中的特定應(yīng)用程序量身制定泛化算法。

– Ralph Johnson and Brian Foote

重構(gòu)測(cè)試用例

因此，代碼需要重構(gòu)。擺脫對(duì)內(nèi)部時(shí)鐘的依賴（DateTime 系統(tǒng)實(shí)用程序）：

 DateTime time = new DateTime();

刪除上述代碼（在你的文件中應(yīng)該是第 7 行）。通過將輸入?yún)?shù) DateTime 時(shí)間添加到 GetDayOrNight 方法，進(jìn)一步重構(gòu)代碼。

這是重構(gòu)的類 DayOrNightUtility.cs：

using System;
 
namespace app {
   public class DayOrNightUtility {
       public string GetDayOrNight(DateTime time) {
           string dayOrNight = "Nighttime";
           if(time.Hour >= 7 && time.Hour < 19) {
               dayOrNight = "Daylight";
           }
           return dayOrNight;
       }
   }
}

重構(gòu)代碼需要更改單元測(cè)試。 需要準(zhǔn)備 nightHour 和 dayHour 的測(cè)試數(shù)據(jù)，并將這些值傳到GetDayOrNight 方法中。 以下是重構(gòu)的單元測(cè)試：

using System;
using Xunit;
using app;
 
namespace unittest
{
   public class UnitTest1
   {
       DayOrNightUtility dayOrNightUtility = new DayOrNightUtility();
       DateTime nightHour = new DateTime(2019, 08, 03, 19, 00, 00);
       DateTime dayHour = new DateTime(2019, 08, 03, 07, 00, 00);
 
       [Fact]
       public void Given7pmReturnNighttime()
       {
           var expected = "Nighttime";
           var actual = dayOrNightUtility.GetDayOrNight(nightHour);
           Assert.Equal(expected, actual);
       }
 
       [Fact]
       public void Given7amReturnDaylight()
       {
           var expected = "Daylight";
           var actual = dayOrNightUtility.GetDayOrNight(dayHour);
           Assert.Equal(expected, actual);
       }
 
   }
}

經(jīng)驗(yàn)教訓(xùn)

在繼續(xù)開發(fā)這種簡單的場景之前，請(qǐng)先回顧復(fù)習(xí)一下本次練習(xí)中所學(xué)到的東西。

運(yùn)行無法測(cè)試的代碼，很容易在不經(jīng)意間制造陷阱。從表面上看，這樣的代碼似乎可以正常工作。但是，遵循測(cè)試驅(qū)動(dòng)開發(fā)（TDD）的實(shí)踐（首先描述期望結(jié)果，然后才描述實(shí)現(xiàn)），暴露了代碼中的嚴(yán)重問題。

這表明 TDD 是確保代碼不會(huì)太凌亂的理想方法。TDD 指出了一些問題區(qū)域，例如缺乏單一責(zé)任和存在隱藏輸入。此外，TDD 有助于刪除不確定性代碼，并用行為明確的完全可測(cè)試代碼替換它。

最后，TDD 幫助交付易于閱讀、邏輯易于遵循的代碼。