變異測試：如何利用故障？

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

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

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

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

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

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

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

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

誰把貓放出來？


在敏捷開發環境中，通過定義期望結果開始構建解決方案會很有幫助。通常，在 用戶故事 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。現在，單元測試通過。

測試驅動解決方案的開始

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

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

via: https://opensource.com/article/19/9/mutation-testing-example-tdd

作者：Alex Bunardzic 選題：lujun9972 譯者：Morisun029 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive