重溫《單元測試的藝術》，總結常用知識點

1. 前言關於單元測試的定義和好處可以借用Stephen Cleary的一段話來概括：單元測試是現代開發的基礎。對項目進行單元測試的好處非常容易理解：單元測試降低了 Bug 數量，縮短了上市時間，防止過度耦合的設計。這些都是很好的優勢，但它還有更多與開發人員更直接相關的優點。在我編寫單元測試時， ...

1. 前言

關於單元測試的定義和好處可以借用Stephen Cleary的一段話來概括：

單元測試是現代開發的基礎。對項目進行單元測試的好處非常容易理解：單元測試降低了 Bug 數量，縮短了上市時間，防止過度耦合的設計。這些都是很好的優勢，但它還有更多與開發人員更直接相關的優點。在我編寫單元測試時，我會對代碼更有信心。在已測試的代碼中更易於添加功能或修複 Bug，因為在代碼發生更改時，單元測試起著安全網的作用。

前幾個月重溫了單元測試的藝術。畢竟是14年的書內容有點舊，於是試著結合書中的內容和一些新的知識點寫進這篇文章，希望對自己及各位讀者有幫助。

TDD是另一個話題，這裡就不涉及了。

2. 選擇單元測試框架

《單元測試的藝術》書中推薦NUnit，VS2019中新建單元測試項目只有MSTest V2、NUnit和xUnit三種。微軟自己的項目也不一定會使用MSTest，例如CoreFX就在用xUnit。

不過我更喜歡MSTest V2，因為從舊的MSTest升級過來幾乎沒有學習成本，也不用向上司解釋為什麼要換框架。MSTest已經是個開源項目，WindowsCommunityToolkit就在用MSTest。

3. 怎麼給單元測試命名

萬事起頭難，最難的就是命名。OnResolveShouldAddSearchDirectoryListOnANeedToBasis這種命名簡直嚇死人，明明覺得每個單詞都認得但感覺就是看不明白。

《單元測試的藝術》書中推薦了一組測試命名的規則。

項目創建一個名為[ProjectUnderTest].UnitTests的測試項目。
類對應被測試項目中的一個淚，創建一個名為[Classname]Tests的類。
工作單元 對每個工作單元（一個方法，或者幾個方法組成的一個邏輯組，或者及各類），創建一個如下命名的測試方法：[UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehavior]。

測試方法名稱的三個部分：

UnitOfWorkName，被測試的方法、一組方法或者一組類。
Scenario，測試進行的假設條件。
ExpectedBehavior，在測試場景指定的條件下，你對被測試方法行為的語氣。

從一個簡單的類開始解釋這個命名規則：

public class LogAnalyzer
{
    public bool IsValidLogFileName(string fileName)
    {
        if (fileName.EndsWith(".SLF") == false)
            return false;

        return true;
    }
}

為這個函數創建對應的單元測試，假設我們傳入錯誤的文件名，預期返回False，則測試方法命名為IsValidLogFileName_BadExtension_ReturnFalse。不需要在函數名中加入“Test”，這種命名本身已暗示自己是個測試方法。

namespace LogAn.UnitTests
{
    [TestClass()]
    public class LogAnalyzerTests
    {
        [TestMethod()]
        public void IsValidLogFileName_BadExtension_ReturnsFalse()
        {
            Assert.Fail();
        }
    }
}

4. 單元測試的組成

單元測試通常包含三個行為：

準備(Arrange)隊形，創建對象，進行必要的設置；
操作(Act)對象；
斷言(Assert)某件事情是預期的。

以IsValidLogFileName_BadExtension_ReturnFalse為例：

[TestMethod()]
public void IsValidLogFileName_BadExtension_ReturnsFalse()
{
    var analyzer = new LogAnalyzer();//Arrange
    var result = analyzer.IsValidLogFileName("filewithbadextension.foo");//Act
    Assert.IsFalse(result);//Assert
}

5. 一些MSTest常用的功能

5.1 參數化測試

要覆蓋多個測試用例可以使用DataRow實現參數化測試（MSTest V1沒有這個Attribute），並且可以為每一個測試用例命名，運行測試後可以看到測試用例的名稱：

[TestMethod()]
[DataRow("filewithbadextension.foo")]
[DataRow("somefile.exe")]
public void IsValidLogFileName_BadExtension_ReturnsFalse(string fileName)
{
    var analyzer = new LogAnalyzer();
    var result = analyzer.IsValidLogFileName(fileName);
    Assert.IsFalse(result);
}

[TestMethod()]
[DataRow("filewithbadextension.SLF", DisplayName = "A valid fileName")]
[DataRow("somefile.SLF",DisplayName = "An other valid fileName")]
public void IsValidLogFileName_GoodExtension_ReturnsTrue(string fileName)
{
    var analyzer = new LogAnalyzer();
    var result = analyzer.IsValidLogFileName(fileName);
    Assert.IsTrue(result);
}

5.2 捕獲預期的異常

在以前很流行使用ExpectedExceptionAttribute檢查異常，代碼如下：

[TestMethod()]
[ExpectedException(typeof(ArgumentNullException))]
public void IsValidLogFileName_EmptyFileName_Throws()
{
    var analyzer = new LogAnalyzer();
    analyzer.IsValidLogFileName(null);
}

這個方法有一些問題：

沒有Assert語句。
如果測試代碼很多，用戶將搞不清楚到底哪行拋出了異常。

更好的做法是使用Assert.ThrowsException(Action, String, Object[])：

[TestMethod()]
public void IsValidLogFileName_EmptyFileName_Throws()
{
    var analyzer = new LogAnalyzer();
    Assert.ThrowsException<ArgumentNullException>(()=>analyzer.IsValidLogFileName(null));
}

5.3 Initialize和Cleanup

進行單元測試時，很重要的一點是保證之前測試的遺留數據或者實例得到銷毀，新測試的狀態是重建的，就好像之前沒有測試運行過一樣。
MSTest提供了一組Attribute用於初始化及釋放資源。

Attribute	功能
AssemblyInitialize()	執行程式集中的所有測試之前運行
ClassInitialize()	測試類中的任意測試執行之前運行
TestInitialize()	測試之前要運行
TestCleanup()	測試之後運行
ClassCleanup()	測試類中所有的測試都執行以後運行
AssemblyCleanup()	執行程式集中的所有測試之後運行

[AssemblyInitialize()]
public static void AssemblyInit(TestContext context)
{
    Debug.WriteLine("AssemblyInit " + context.TestName);
}

[ClassInitialize()]
public static void ClassInit(TestContext context)
{
    Debug.WriteLine("ClassInit " + context.TestName);
}

[TestInitialize()]
public void Initialize()
{
    Debug.WriteLine("TestMethodInit");
}

[TestCleanup()]
public void Cleanup()
{
    Debug.WriteLine("TestMethodCleanup");
}

[ClassCleanup()]
public static void ClassCleanup()
{
    Debug.WriteLine("ClassCleanup");
}

[AssemblyCleanup()]
public static void AssemblyCleanup()
{
    Debug.WriteLine("AssemblyCleanup");
}

輸出結果如下：

AssemblyInit IsValidLogFileName_EmptyFileName_Throws
ClassInit IsValidLogFileName_EmptyFileName_Throws
TestMethodInit
TestMethodCleanup
TestMethodInit
TestMethodCleanup
TestMethodInit
TestMethodCleanup
TestMethodInit
TestMethodCleanup
TestMethodInit
TestMethodCleanup
ClassCleanup
AssemblyCleanup

6. Stub（存根）和Mock（模擬對象）

外部依賴項常常是不寫單元測試的藉口，如文件系統、網路服務甚至系統時間，開發者往往說沒法控制而逃避寫單元測試。這種情況可以使用stub或mock破除依賴。

6.1 Stub(存根)

一個存根(stub)是對系統中存在的一個依賴項(又或者協作者)的可控制的替代物。通過使用存根，你在測試代碼無需直接處理這個依賴項。

如果前面的LogAnalyzer改成如下形式：

public bool IsValidLogFileName(string fileName)
{
    //讀取配置文件，由配置文件判斷是否支持這個擴展名
}

一旦測試依賴了文件系統，你進行的就是集成測試，帶來了所有集成測試相關的問題————運行速度慢，需要配置等等。這種情況下可以使用一個stub代替文件系統的依賴。

public class LogAnalyzer
{
    private IExtensionManager _manager;

    public LogAnalyzer(IExtensionManager manager) //定義測試代碼可以調用的構造函數
    {
        _manager = manager;
    }

    public bool IsValidLogFileName(string fileName)
    {
        return _manager.IsValid(fileName);
    }
}


public interface IExtensionManager
{
    bool IsValid(string fileName);
}

internal class FakeExtensionManager : IExtensionManager //定義一個最簡單的stub
{
    public bool WillBeValid { get; set; } = false;

    public bool IsValid(string fileName)
    {
        return WillBeValid;
    }
}

[TestMethod()]
public void IsValidLogFileName_NameSupportedExtension_ReturnsTrue()
{
    var myFakeManager = new FakeExtensionManager { WillBeValid = true }; //準備一個返回true的stub
    var analyzer = new LogAnalyzer(myFakeManager); //傳入stub
    var result = analyzer.IsValidLogFileName("short.ext");
    Assert.IsTrue(result);
}

註入stub的方式由很多，《單元測試的藝術》中有詳細的介紹，這裡略過。

6.2 Mock（模擬對象）

模擬對象(Mock)是系統中的偽對象，它可以驗證被測試對象是否按照預期的方式調用了這個偽對象，因此導致單元測試通過或者失敗。通常每個測試最多有一個模擬對象。

這次LogAnalyer需要和一個外部的Web服務交互，每次LogAnalyer遇到一個過短的文件名，這個Web服務就會收到一個錯誤消息。遺憾的是，你要測試的這個Wen服務還沒有完全實現，就算實現了，使用這個Web服務會導致測試時間過長。因此這裡需要一個Mock，這個Mock只包括需要調用的Web服務方法，然後LogAnalyzer調用這個介面寫錯誤日誌。

public interface IWebService
{
    void LogError(string message);
}

public class LogAnalyzer
{
    private IWebService _service;

    public LogAnalyzer(IWebService service) //定義測試代碼可以調用的構造函數
    {
        _service= service;
    }

    public void Analyze(string fileName)
    {
        if (fileName.Length < 9)
            _service.LogError("Filename too short:" + fileName); //在產品代碼中寫錯誤日誌
    }
}

使用mock對象測試LogAnalyzer，註意是對mock對象進行斷言，而非LogAnalyer類，因為測試的是LogAnalyer和Web服務之間的交互:

public class FakeWebService : IWebService //定義一個最簡單的mock
{
    public string LastError { get; private set; }

    public void LogError(string message)
    {
        LastError = message;
    }
}


[TestMethod()]
public void Analyze_TooShrtFileName_CallsWebService()
{
    var mockService = new FakeWebService();
    var analyzer = new LogAnalyzer(mockService);
    var tooShortFileName = "abc.ext";
    analyzer.Analyze(tooShortFileName);
    StringAssert.Contains(mockService.LastError, tooShortFileName); //對模擬對象進行斷言
}

6.3 Stub（存根）和Mock（模擬對象）和Fake(偽對象)

Fake(偽對象)是通用的術語，可以描述一個stub或mock，，因為stub和mock看想去都很像真實對象。一個偽對象究竟是stub還是mock取決於它在當前測試中的使用方式：如果這個偽對象用來檢驗一個交互(對其進行斷言)，它就是mock，否則就是stub。

如果一個測試只測試一件事情，測試中應該最多只有一個mock，所有其它的偽對象都是stub。如果一個測試有多個mock，這說明你在測試多件事情，會導致測試過於複雜或脆弱。

前面定義的Stub和Mock都使用了Fake-首碼，因為在類中避免使用"mock"和"stub"，那麼這個類的對象就可以具有兩種行為方式，以後再不同的測試中重用。

7. 隔離框架

手工編寫偽對象有很多問題，最明顯的問題就是產生大量的編碼和維護工作。使用隔離框架是一個更優雅的方案，它可以在運行時動創建和配置偽對象。

.NET的隔離框架有很多，《單元測試的藝術》書中以NSubstitute(簡稱NSub)為例介紹了隔離框架的基本用法(看起來最近nuget下載量比moq更多)。

這一節介紹一些NSub的基本操作，更多的內容詳見官網。

7.1 創建偽對象

假設我們有一個介面：

public interface ICalculator
{
    int Add(int a, int b);
    string Mode { get; set; }
    event Action PoweringUp;
}

NSub用下麵的代碼創建一個偽對象：

_calculator = Substitute.For<ICalculator>();

NSub能自動生成偽對象，這個偽造的ICalculator對象實例時動態生成的，實現了ICalculator介面，但沒有實現它的任何方法。從模擬對象創建到測試方式結束，對這個模擬對象的所有調用都會自動記錄，保存供後來使用。

7.2 模擬值

使用Returns模擬函數值並斷言：

_calculator.Add(1, 2).Returns(3);
Assert.AreEqual(_calculator.Add(1, 2), 3);

模擬屬性值並斷言：

_calculator.Mode.Returns("DEC");
Assert.AreEqual(_calculator.Mode, "DEC");

_calculator.Mode = "HEX";
Assert.AreEqual(_calculator.Mode, "HEX");

也可以模擬一組值並逐個斷言：

_calculator.Mode.Returns("HEX", "DEC", "BIN");
Assert.AreEqual(_calculator.Mode, "HEX");
Assert.AreEqual(_calculator.Mode, "DEC");
Assert.AreEqual(_calculator.Mode, "BIN");

7.3 測試交互

使用Received斷言接收到調用，以及DidNotReceive斷言沒接收到調用：

_calculator.Add(1, 2);
_calculator.Received().Add(1, 2);
_calculator.DidNotReceive().Add(5, 7);

7.4 參數匹配器

Arg類成為參數匹配器，用於控制參數處理：

_calculator.Add(10, -5);
_calculator.Received().Add(10, Arg.Any<int>()); //斷言第二個參數時int類型
_calculator.Received().Add(10, Arg.Is<int>(x => x < 0)); //斷言第二個參數小於5

使用參數匹配器並傳入一個function到Returns可以更好地控制返回值：

_calculator.Add(Arg.Any<int>(), Arg.Any<int>())
           .Returns(x => (int)x[0] + (int)x[1]);
Assert.AreEqual(_calculator.Add(5, 10), 15);

7.5 使用When模擬異常

_calculator.When(x => x.Add(Arg.Is<int>(i => i < 0), Arg.Any<int>()))
    .Do(context => throw new ArgumentException("invalid"));

Assert.ThrowsException<ArgumentException>(() => _calculator.Add(-5, 0));

這裡When後面的Lambda指示當第一個參數小於0，然後用Do拋出一個異常。

7.6 測試事件

var eventWasRaised = false;
_calculator.PoweringUp += () => eventWasRaised = true;

_calculator.PoweringUp += Raise.Event<Action>();
Assert.IsTrue(eventWasRaised);

NSub使用Raise觸發事件。

8. 其它

8.1 區分單元測試和集成測試

任何測試，如果它運行速度不快，結果不穩定，或者要用到被測試單元的一個或多個真實依賴物，我就認為它是集成測試。

集成測試是對一個工作單元進行的測試，這個測試對被測試的工作單元沒有完全的控制，並使用該單元的一個或多個真實依賴物，例如事件、網路、資料庫、線程或隨機數產生器等。

集成測試和單元測試的項目應該分開。一般來說，複雜的測試都是集成測試，由於集成測試很慢，可以考慮使用創建一個只包含單元測試的解決方案，這樣才可以頻繁頻繁地執行測試，實行TDD。

8.2 如何測試私有方法

私有方法通常比較難測試，不過你可以這麼想：私有方法不會無緣無故地存在，最終在某個地方有公共方法會調用這個私有方法。看到一個私有方法的時候，你應該找到使用這個方法的公共用例並對這個公共用例進行測試。

如果一個私有方法真的值得進行測試，那麼它也許應該設為公共的，靜態的。有幾種方式處理私有方法：

使方法成為公共方法。如果它真的那麼重要，那把它設為公共的並不一定是壞事。使它變成正式的公共契約可以防止它被任意破壞。
把方法提取到新類。
使方法成為靜態方法。
使方法成為內部方法並使用InternalsVisibleTo。

8.3 用代碼審查確保代碼覆蓋率

代碼覆蓋率100%說明什麼呢？如果沒有做代碼審查，這個覆蓋率不能說明什麼。也許這些測試連斷言都沒有，只是為了達到更高的覆蓋率所寫的代碼。如果你做了代碼審查和測試審查，確保測試優秀而且覆蓋了所有代碼，那麼你就擁有了一個安全網，可以避免愚蠢的錯誤，同時團隊也獲得了分享的知識，從持續的學習中獲益。

9. 結語

雖然《單元測試的藝術》是一本有點舊的書，但我是不是還是會拿出來重溫並推薦給別人，畢竟.NET專門講單元測試的書不多。如果有其它單元測試方面的優秀書籍請推薦給我。

另外，微軟的單元測試基礎也是個很不錯的文檔。

10. 參考

單元測試 - Visual Studio Microsoft Docs

Microsoft.VisualStudio.TestTools.UnitTesting Namespace Microsoft Docs

NSubstitute A friendly substitute for .NET mocking libraries