變異測試：基於故障的試驗

在本系列的第一篇文章中，我演示了如何使用設計的故障來確保代碼中的預期結果。在第二篇文章中，我將繼續開發示例項目：一款自動貓門，該門在白天開放，夜間鎖定。

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

關於白天時間

回想一下，測試驅動開發（TDD）圍繞著大量的單元測試。

第一篇文章中實現了滿足 Given7pmReturnNighttime 單元測試期望的邏輯。但還沒有完，現在，你需要描述當前時間大於 7 點時期望發生的結果。這是新的單元測試，稱為 Given7amReturnDaylight：

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

現在，新的單元測試失敗了（越早失敗越好！）：

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

期望接收到字元串值是 Daylight，但實際接收到的值是 Nighttime。

分析失敗的測試用例

經過仔細檢查，代碼本身似乎已經出現問題。 事實證明，GetDayOrNight 方法的實現是不可測試的！

看看我們面臨的核心挑戰：

1. GetDayOrNight 依賴隱藏輸入。

dayOrNight 的值取決於隱藏輸入（它從內置系統時鐘中獲取一天的時間值）。

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

從系統時鐘中獲取到的時間值是不確定的。（因為）該時間取決於你運行代碼的時間點，而這一點我們認為這是不可預測的。

3. GetDayOrNight API 的質量差。

該 API 與具體的數據源（系統 DateTime）緊密耦合。

4. GetDayOrNight 違反了單一責任原則。

該方法實現同時使用和處理信息。優良作法是一種方法應負責執行一項職責。

5. GetDayOrNight 有多個更改原因。

可以想像內部時間源可能會更改的情況。同樣，很容易想像處理邏輯也將改變。這些變化的不同原因必須相互隔離。

6. 當（我們）嘗試了解 GetDayOrNight 行為時，會發現它的 API 簽名不足。

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

7. GetDayOrNight 取決於全局共享可變狀態。

要不惜一切代價避免共享的可變狀態！

8. 即使在閱讀源代碼之後，也無法預測 GetDayOrNight 方法的行為。

這是一個嚴重的問題。通過閱讀源代碼，應該始終非常清晰，系統一旦開始運行，便可以預測出其行為。

失敗背後的原則

每當你遇到工程問題時，建議使用久經考驗的 分而治之 divide and conquer 策略。在這種情況下，遵循 關注點分離 separation of concerns 的原則是一種可行的方法。

關注點分離（SoC）是一種用於將計算機程序分為不同模塊的設計原理，以便每個模塊都可以解決一個關注點。關注點是影響計算機程序代碼的一組信息。關注點可以和要優化代碼的硬體的細節一樣概括，也可以和要實例化的類的名稱一樣具體。完美體現 SoC 的程序稱為模塊化程序。

（出處）

GetDayOrNight 方法應僅與確定日期和時間值表示白天還是夜晚有關。它不應該與尋找該值的來源有關。該問題應留給調用客戶端。

必須將這個問題留給調用客戶端，以獲取當前時間。這種方法符合另一個有價值的工程原理—— 控制反轉 inversion of control 。Martin Fowler 在這裡詳細探討了這一概念。

框架的一個重要特徵是用戶定義的用於定製框架的方法通常來自於框架本身，而不是從用戶的應用程序代碼調用來的。該框架通常在協調和排序應用程序活動中扮演主程序的角色。控制權的這種反轉使框架有能力充當可擴展的框架。用戶提供的方法為框架中的特定應用程序量身制定泛化演算法。

– Ralph Johnson and Brian Foote

重構測試用例

因此，代碼需要重構。擺脫對內部時鐘的依賴（DateTime 系統實用程序）：

 DateTime time = new DateTime();

刪除上述代碼（在你的文件中應該是第 7 行）。通過將輸入參數 DateTime 時間添加到 GetDayOrNight 方法，進一步重構代碼。

這是重構的類 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;
       }
   }
}

重構代碼需要更改單元測試。 需要準備 nightHour 和 dayHour 的測試數據，並將這些值傳到GetDayOrNight 方法中。 以下是重構的單元測試：

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);
       }

   }
}

經驗教訓

在繼續開發這種簡單的場景之前，請先回顧複習一下本次練習中所學到的東西。

運行無法測試的代碼，很容易在不經意間製造陷阱。從表面上看，這樣的代碼似乎可以正常工作。但是，遵循測試驅動開發（TDD）的實踐（首先描述期望結果，然後才描述實現），暴露了代碼中的嚴重問題。

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

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

在本系列的下一篇文章中，我將演示如何使用在本練習中創建的邏輯來實現功能代碼，以及如何進行進一步的測試使其變得更好。

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

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

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

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