使用事先設計好的故障以確保你的代碼達到預期的結果，并遵循 .NET xUnit.net 測試框架來進行測試。

 

[[279678]]

在變異測試是 TDD 的演變 一文中，我談到了迭代的力量。在可度量的測試中，迭代能夠保證找到問題的解決方案。在那篇文章中，我們討論了迭代法幫助確定實現計算給定數字平方根的代碼。

我還演示了最有效的方法是找到可衡量的目標或測試，然后以最佳猜測值開始迭代。正如所預期的，第一次測試通常會失敗。因此，必須根據可衡量的目標或測試對失敗的代碼進行完善。根據運行結果，對測試值進行驗證或進一步加以完善。

在此模型中，學習獲得解決方案的唯一方法是反復失敗。這聽起來有悖常理，但它確實有效。

按照這種分析，本文探討了在構建包含某些依賴項的解決方案時使用 DevOps 的好方法。第一步是編寫一個預期結果失敗的用例。

依賴性問題是你不能依賴它們

正如邁克爾·尼加德Michael Nygard在《沒有終結狀態的架構》中機智的表示的那樣，依賴問題是一個很大的話題，最好留到另一篇文章中討論。在這里，你將會看到依賴項給項目帶來的一些潛在問題，以及如何利用測試驅動開發（TDD）來避免這些陷阱。

首先，找到現實生活中的一個挑戰，然后看看如何使用 TDD 解決它。

誰把貓放出來？

 

[[279679]]

一只貓站在屋頂

在敏捷開發環境中，通過定義期望結果開始構建解決方案會很有幫助。通常，在 用戶故事user story 中描述期望結果：

我想使用我的家庭自動化系統（HAS）來控制貓何時可以出門，因為我想保證它在夜間的安全。

現在你已經有了一個用戶故事，你需要通過提供一些功能要求（即指定驗收標準）來對其進行詳細說明。 從偽代碼中描述的最簡單的場景開始：

場景 1：在夜間關閉貓門

• 用時鐘監測到了晚上的時間
• 時鐘通知 HAS 系統
• HAS 關閉支持物聯網（IoT）的貓門

分解系統

開始構建之前，你需要將正在構建的系統（HAS）進行分解（分解為依賴項）。你必須要做的第一件事是識別任何依賴項（如果幸運的話，你的系統沒有依賴項，這將會更容易，但是，這樣的系統可以說不是非常有用）。

從上面的簡單場景中，你可以看到所需的業務成果（自動控制貓門）取決于對夜間情況監測。這種依賴性取決于時鐘。但是時鐘是無法區分白天和夜晚的。需要你來提供這種邏輯。

正在構建的系統中的另一個依賴項是能夠自動訪問貓門并啟用或關閉它。該依賴項很可能取決于具有 IoT 功能的貓門提供的 API。

依賴管理面臨快速失敗

為了滿足依賴項，我們將構建確定當前時間是白天還是晚上的邏輯。本著 TDD 的精神，我們將從一個小小的失敗開始。

有關如何設置此練習所需的開發環境和腳手架的詳細說明，請參閱我的上一篇文章。我們將重用相同的 NET 環境和 xUnit.net 框架。

接下來，創建一個名為 HAS（“家庭自動化系統”）的新項目，創建一個名為 UnitTest1.cs 的文件。在該文件中，編寫第一個失敗的單元測試。在此單元測試中，描述你的期望結果。例如，當系統運行時，如果時間是晚上 7 點，負責確定是白天還是夜晚的組件將返回值 Nighttime。

這是描述期望值的單元測試：

using System;
using Xunit;
 
namespace unittest
{
   public class UnitTest1
   {
       DayOrNightUtility dayOrNightUtility = new DayOrNightUtility();
 
       [Fact]
       public void Given7pmReturnNighttime()
       {
           var expected = "Nighttime";
           var actual = dayOrNightUtility.GetDayOrNight();
           Assert.Equal(expected, actual);
       }
   }
}

至此，你可能已經熟悉了單元測試的結構?？焖購土曇幌拢涸诖耸纠?，通過給單元測試一個描述性名稱Given7pmReturnNighttime 來描述期望結果。然后，在單元測試的主體中，創建一個名為 expected 的變量，并為該變量指定期望值（在該示例中，值為 Nighttime）。然后，為實際值指定一個 actual（在組件或服務處理一天中的時間之后可用）。

最后，通過斷言期望值和實際值是否相等來檢查是否滿足期望結果：Assert.Equal(expected, actual)。

你還可以在上面的列表中看到名為 dayOrNightUtility 的組件或服務。該模塊能夠接收消息GetDayOrNight，并且返回 string 類型的值。

同樣，本著 TDD 的精神，描述的組件或服務還尚未構建（僅為了后面說明在此進行描述）。構建這些是由所描述的期望結果來驅動的。

在 app 文件夾中創建一個新文件，并將其命名為 DayOrNightUtility.cs。將以下 C＃ 代碼添加到該文件中并保存：

using System;
 
namespace app {
   public class DayOrNightUtility {
       public string GetDayOrNight() {
           string dayOrNight = "Undetermined";
           return dayOrNight;
       }
   }
}

現在轉到命令行，將目錄更改為 unittests 文件夾，然后運行：

[Xunit.net 00:00:02.33] unittest.UnitTest1.Given7pmReturnNighttime [FAIL]
Failed unittest.UnitTest1.Given7pmReturnNighttime
[...]

恭喜，你已經完成了第一個失敗的單元測試。單元測試的期望結果是 DayOrNightUtility 方法返回字符串 Nighttime，但相反，它返回是 Undetermined。

修復失敗的單元測試

修復失敗的測試的一種快速而粗略的方法是將值 Undetermined 替換為值 Nighttime 并保存更改：

using System;
 
namespace app {
   public class DayOrNightUtility {
       public string GetDayOrNight() {
           string dayOrNight = "Nighttime";
           return dayOrNight;
       }
   }
}

現在運行，成功了。

Starting test execution, please wait...
 
Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 2.6470 Seconds

但是，對值進行硬編碼基本上是在作弊，最好為 DayOrNightUtility 方法賦予一些智能。修改 GetDayOrNight 方法以包括一些時間計算邏輯：

public string GetDayOrNight() {
    string dayOrNight = "Daylight";
    DateTime time = new DateTime();
    if(time.Hour < 7) {
        dayOrNight = "Nighttime";
    }
    return dayOrNight;
}

該方法現在從系統獲取當前時間，并與 Hour 比較，查看其是否小于上午 7 點。如果小于，則處理邏輯將 dayOrNight 字符串值從 Daylight 轉換為 Nighttime?，F在，單元測試通過。

測試驅動解決方案的開始

現在，我們已經開始了基本的單元測試，并為我們的時間依賴項提供了可行的解決方案。后面還有更多的測試案例需要執行。

在下一篇文章中，我將演示如何對白天時間進行測試以及如何在整個過程中利用故障。