0x00 單元測(cè)試Pro & Con

最近嘗試在我參與的游戲項(xiàng)目中引入TDD（測(cè)試驅(qū)動(dòng)開(kāi)發(fā)）的開(kāi)發(fā)模式，因此單元測(cè)試便變得十分必要。這篇博客就來(lái)聊一聊這段時(shí)間的感悟和想法。由于游戲開(kāi)發(fā)和傳統(tǒng)軟件開(kāi)發(fā)之間的差異，因此在開(kāi)發(fā)游戲，特別是使用Unity3D開(kāi)發(fā)游戲的過(guò)程中編寫(xiě)單元測(cè)試往往會(huì)面臨兩個(gè)主要的問(wèn)題：

1. 游戲開(kāi)發(fā)中會(huì)涉及到很多的I/O操作處理，以及視覺(jué)和UI的處理，而這個(gè)部分是單元測(cè)試中比較難以處理的部分。
2. 具體到使用Unity3D開(kāi)發(fā)游戲，我們自然而然的希望能夠?qū)y(cè)試的框架集成到Unity3D的編輯器中，這樣更加容易操作。

但是，單元測(cè)試的好處也十分多。

1. TDD，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)。編寫(xiě)單元測(cè)試將使我們從調(diào)用者觀察、思考。特別是先寫(xiě)測(cè)試，迫使我們把程序設(shè)計(jì)成易于調(diào)用和可測(cè)試的，即迫使我們解除軟件中的耦合。可以將任務(wù)的粒度降低。當(dāng)然TDD是否適合游戲開(kāi)發(fā)尚有爭(zhēng)論，但是單元測(cè)試的必要性是無(wú)需置疑的。
2. 單元測(cè)試是一種無(wú)價(jià)的文檔，它是展示方法或類(lèi)如何使用的最佳文檔。這份文檔是可編譯、可運(yùn)行的，并且它保持最新，永遠(yuǎn)與代碼同步。
3. 更加適合應(yīng)對(duì)需求的經(jīng)常性變更。身處游戲開(kāi)發(fā)行業(yè)的從業(yè)人員都不能否認(rèn)的一點(diǎn)便是游戲開(kāi)發(fā)中需求變更是一件不可避免甚至是必不可少的事情，而單元測(cè)試另一個(gè)好處便是一旦因?yàn)樾枨笞兏霈F(xiàn)bug，能夠很快的發(fā)現(xiàn)，進(jìn)而解決問(wèn)題。

0x01 Unity3D中常用的測(cè)試工具

針對(duì)問(wèn)題1，由于對(duì)I/O處理以及UI視覺(jué)方面的操作比較難以實(shí)施單元測(cè)試，所以我們單元測(cè)試的主要對(duì)象是邏輯操作以及數(shù)據(jù)存取的部分。
針對(duì)問(wèn)題2，Unity5.3.x已經(jīng)在editor中集成了測(cè)試模塊。該測(cè)試模塊依托了NUnit框架（NUnit是一個(gè)單元測(cè)試框架,專(zhuān)門(mén)針對(duì)于.NET來(lái)寫(xiě)的.其實(shí)在前面有JUnit(Java),CPPUnit(C++),他們都是xUnit的一員.最初,它是從JUnit而來(lái).U3d使用的版本是2.6.4）。
在Unity Editor中實(shí)現(xiàn)測(cè)試而不是在IDE中進(jìn)行測(cè)試的原因在于，一些Unity的API需要在Unity的環(huán)境中來(lái)運(yùn)行，而無(wú)法直接在外部的IDE中實(shí)現(xiàn)，例如實(shí)例化GameObject。
而且除了Unity5.3.x自帶的單元測(cè)試模塊之外，Unity官方還推出了一款測(cè)試插件Unity Test Tool（基于NSubstitute），除了單元測(cè)試之外還包括：

1. 單元測(cè)試
2. 集成測(cè)試
3. 斷言組件

需要指出的是Unity Test Tool基于NSubstitute這個(gè)庫(kù)。

0x02 初識(shí)單元測(cè)試

既然本文的主題是單元測(cè)試，那么我們就必須先對(duì)單元測(cè)試下一個(gè)定義：

一個(gè)單元測(cè)試是一段自動(dòng)化的代碼，這段代碼調(diào)用被測(cè)試的工作單元，之后對(duì)這個(gè)單元的單個(gè)最終結(jié)果的某些假設(shè)進(jìn)行檢驗(yàn)。單元測(cè)試使用單元測(cè)試框架編寫(xiě)，并要求單元測(cè)試可靠、可讀并且可維護(hù)。只要產(chǎn)品代碼不發(fā)生變化，單元測(cè)試的結(jié)果是穩(wěn)定的。

既然有了單元測(cè)試的定義，下面我們就嘗試在Unity項(xiàng)目中寫(xiě)單元測(cè)試吧。

一個(gè)單元測(cè)試的小例子：

編寫(xiě)單元測(cè)試用例時(shí)，使用的主要是Unity Editor自帶的單元測(cè)試模塊，因此單元測(cè)試是基于NUnit框架的。
借助NUnit，我們可以：

1. 編寫(xiě)結(jié)構(gòu)化的測(cè)試。
2. 自動(dòng)執(zhí)行選中的或全部的單元測(cè)試。
3. 查看測(cè)試運(yùn)行的結(jié)果。

因此這就要求編寫(xiě)Unity3D項(xiàng)目的單元測(cè)試時(shí)，要引入NUnit.Framework命名空間，且單元測(cè)試類(lèi)要加上[TestFixture]屬性，單元測(cè)試方法要加上[Test]屬性，并將測(cè)試用例的文件放在Editor文件夾下。
下面是一個(gè)例子：

using UnityEngine;
using System.Collections;
using NUnit.Framework;

[TestFixture]
public class HpCompTests
{
  //測(cè)試被攻擊之后傷害數(shù)值是否和預(yù)期值相等
  [Test]
  public void TakeDamage_BeAttacked_HpEqual()
{
  //Arrange
      HpComp health = new HpComp();
      health.currentHp = 100;
     //Act
      health.TakeDamage(50);
     //Assert
      Assert.AreEqual(50f, health.currentHp);
    }
}

該例子是測(cè)試英雄受到傷害之后，血量是否和預(yù)期的相等。
測(cè)試框架會(huì)創(chuàng)建這個(gè)測(cè)試用例類(lèi)，并且調(diào)用TakeDamage_BeAttacked_HpEqual方法來(lái)和其交互，最后使用Nunit的Assert類(lèi)來(lái)斷言是否通過(guò)測(cè)試。

0x03 單元測(cè)試的結(jié)構(gòu)

通過(guò)上面的小例子，我們可以發(fā)現(xiàn)單元測(cè)試其實(shí)是有結(jié)構(gòu)的。下面我們就來(lái)具體分析一下：

使用NUnit提供的特性來(lái)標(biāo)識(shí)測(cè)試代碼

NUnit使用C#的特性機(jī)制識(shí)別和加載測(cè)試。這些特性就像是書(shū)簽，用來(lái)幫助測(cè)試框架識(shí)別哪些部分是需要調(diào)用的測(cè)試。
如果要使用NUnit的特性，我們需要在測(cè)試代碼中首先引入NUnit.Framework命名空間。
而NUnit運(yùn)行器至少需要兩個(gè)特性才知道需要運(yùn)行什么。

1. [TestFixture]：標(biāo)識(shí)一個(gè)自動(dòng)化NUnit測(cè)試的類(lèi)。
2. [Test]：可以加在一個(gè)方法上，標(biāo)識(shí)這個(gè)方法是一個(gè)需要調(diào)用的自動(dòng)化測(cè)試。

當(dāng)然，還有一些別的特性供我們使用，來(lái)方便我們更好的控制測(cè)試代碼，例如[Category]特性可以將測(cè)試分類(lèi)、[Ignore]特性可以忽略測(cè)試。
常用的NUnit屬性見(jiàn)下表：

[SetUp] 
[TearDown]  
[TestFixture] 
[Test] 
[TestCase] 
[Category] 
[Ignore] 

測(cè)試命名和布局標(biāo)準(zhǔn)

測(cè)試類(lèi)的命名：
對(duì)應(yīng)被測(cè)試項(xiàng)目中的一個(gè)類(lèi)，創(chuàng)建一個(gè)名為[ClassName]Tests的類(lèi)。
工作單元的命名：
對(duì)每個(gè)工作單元（測(cè)試），測(cè)試方法的方法名由三部分組成，并且按照如下規(guī)則命名：[被測(cè)試的方法名]_[測(cè)試進(jìn)行的假設(shè)條件]_[對(duì)測(cè)試方法的預(yù)期]。
具體來(lái)說(shuō)：

1. 被測(cè)試的方法名
2. 測(cè)試進(jìn)行的假設(shè)條件，例如“登入失敗”、“無(wú)效用戶”、“密碼正確”。
3. 對(duì)測(cè)試方法的預(yù)期：在測(cè)試場(chǎng)景指定的條件下，我們對(duì)被測(cè)試方法的行為的預(yù)期。

其中，對(duì)測(cè)試方法的預(yù)期會(huì)有三種可能的結(jié)果：

1. 返回一個(gè)值（數(shù)值、布爾值等等）。
2. 改變被測(cè)試的系統(tǒng)的一個(gè)狀態(tài)。
3. 調(diào)用一個(gè)第三方系統(tǒng)。

可以看出，我們的測(cè)試代碼在格式上與標(biāo)準(zhǔn)的代碼有所不同，測(cè)試名可以很長(zhǎng)，但是在編寫(xiě)測(cè)試代碼時(shí)，可讀性是最為重要的方面之一，而測(cè)試名中的下劃線可以令我們不會(huì)遺漏所有的重要信息，我們甚至可以將測(cè)試方法名當(dāng)做一個(gè)句子來(lái)讀，這樣就會(huì)使得這個(gè)測(cè)試方法的測(cè)試目標(biāo)、場(chǎng)景以及預(yù)期都十分明確，無(wú)需額外的注釋。

測(cè)試單元的行為——3A原則

有了NUnit屬性可以標(biāo)識(shí)可以自動(dòng)運(yùn)行的測(cè)試代碼和測(cè)試代碼的一些命名規(guī)則，下面我們就來(lái)看看如何測(cè)試自己的代碼。
一個(gè)單元測(cè)試通常包含三個(gè)行為，可以歸納為3A原則即：

1. Arrange，準(zhǔn)備對(duì)象，創(chuàng)建對(duì)象并進(jìn)行必要的設(shè)置。
2. Act，操作對(duì)象。
3. Assert，斷言某件事情是預(yù)期的。

下面是之前的那段簡(jiǎn)單的代碼，包含了以上的NUnit的屬性、命名規(guī)范以及3A原則下的行為，其中斷言部分使用了NUnit框架提供的Assert類(lèi)，被測(cè)試的類(lèi)為HpComp，被測(cè)試的方法為T(mén)akeDamage。

using NUnit.Framework;

[TestFixture]
public class HpCompTests
{
  //測(cè)試被攻擊之后傷害數(shù)值是否和預(yù)期值相等
  [Test]
  public void TakeDamage_BeAttacked_HpEqual()
{
  //Arrange
      HpComp health = new HpComp();
      health.currentHp = 100;
     //Act
      health.TakeDamage(50);
     //Assert
      Assert.AreEqual(50f, health.currentHp);
    }
}

單元測(cè)試的斷言——Assert類(lèi)

NUnit框架提供了一個(gè)Assert類(lèi)來(lái)處理斷言的相關(guān)功能。Asset類(lèi)用于聲明某個(gè)特定的假設(shè)應(yīng)該成立，因此如果傳遞給Assert類(lèi)的參數(shù)和我們斷言（預(yù)期）的值不同，則NUnit框架會(huì)認(rèn)為測(cè)試沒(méi)有通過(guò)。
Assert類(lèi)會(huì)提供一些靜態(tài)方法，供我們使用。
例如：

Assert.AreEqual(預(yù)期值，實(shí)際值)；
Assert.AreEqual(1，2 - 1)；

關(guān)于Assert類(lèi)的靜態(tài)方法，各位可以直接在代碼中看。

0x04 單元測(cè)試的可靠性

我們的目標(biāo)是寫(xiě)出可靠、可維護(hù)、可讀的測(cè)試。
因此，除了遵循單元測(cè)試結(jié)構(gòu)規(guī)范編寫(xiě)單元測(cè)試之外，我們還需要注意可靠性、可維護(hù)性以及可讀性這些方面。因此，一些原則我們也需要注意。

不輕易刪除和修改測(cè)試

一旦測(cè)試寫(xiě)好了并且通過(guò)了，就不應(yīng)該輕易的修改和刪除這些測(cè)試。因?yàn)檫@些測(cè)試是對(duì)應(yīng)系統(tǒng)代碼的保護(hù)傘，在修改系統(tǒng)代碼時(shí)，這些測(cè)試會(huì)告訴我們修改后的代碼是否會(huì)破壞已有的功能。

盡量避免測(cè)試中的邏輯

隨著測(cè)試中的邏輯增多，測(cè)試代碼出現(xiàn)缺陷的幾率也會(huì)增大。而且由于我們往往相信測(cè)試是可靠的，因此一旦測(cè)試出現(xiàn)缺陷我們往往不會(huì)首先考慮是測(cè)試的問(wèn)題，可能會(huì)浪費(fèi)時(shí)間去修改系統(tǒng)代碼。而單元測(cè)試中，最好保持邏輯的簡(jiǎn)單，因此盡量避免使用下面的邏輯控制代碼。

1. switch、if
2. foreach、for、while

一個(gè)單元測(cè)試應(yīng)該是一系列的方法調(diào)用和斷言，但是不應(yīng)該包含控制流語(yǔ)句。

只測(cè)試一個(gè)關(guān)注點(diǎn)

在一個(gè)單元測(cè)試中驗(yàn)證多個(gè)關(guān)注點(diǎn)會(huì)使得測(cè)試代碼變得復(fù)雜，但卻沒(méi)有價(jià)值。相反，我們應(yīng)該在分開(kāi)的、獨(dú)立的單元中驗(yàn)證多余的關(guān)注點(diǎn)，這樣才能發(fā)現(xiàn)真正導(dǎo)致失敗的地方。

0x05 單元測(cè)試的可維護(hù)性

去除重復(fù)代碼

和系統(tǒng)中的重復(fù)代碼一樣，在單元測(cè)試中重復(fù)代碼同樣意味著測(cè)試對(duì)象某方面改變時(shí)要修改更多的測(cè)試代碼。
如果測(cè)試看上去都一樣，僅僅是參數(shù)不同，那么我們完全可以使用參數(shù)化測(cè)試即使用[TestCase]特性將不同的數(shù)據(jù)作為參數(shù)傳入測(cè)試方法。

實(shí)施測(cè)試隔離

所謂的測(cè)試隔離，指的是一個(gè)測(cè)試和其他的測(cè)試隔離，甚至不知道其他測(cè)試的存在，而只在自己的小世界中運(yùn)行。
將測(cè)試隔離的目的是防止測(cè)試之間的互相影響，常見(jiàn)的測(cè)試之間互相影響的情況可以總結(jié)如下：

1. 強(qiáng)制的測(cè)試順序：測(cè)試要以某種順序執(zhí)行，后一個(gè)測(cè)試需要前面的測(cè)試結(jié)果，這種情況有可能會(huì)導(dǎo)致問(wèn)題的原因是因?yàn)镹Unit不能保證測(cè)試按照某種特定的順序執(zhí)行，因此今天通過(guò)的測(cè)試，明天可能就不好用了
2. 隱藏的測(cè)試調(diào)用：測(cè)試調(diào)用其他測(cè)試
3. 共享狀態(tài)被破壞：測(cè)試要共享狀態(tài)，但是在一個(gè)測(cè)試完成之后沒(méi)有重置狀態(tài)，進(jìn)而影響后面的測(cè)試

0x06 單元測(cè)試的可讀性

正如概述中所說(shuō)單元測(cè)試是一種無(wú)價(jià)的文檔，它是展示方法或類(lèi)如何使用的最佳文檔。因此，可讀性這條要求的重要性便可見(jiàn)一斑。試想一下即便是幾個(gè)月之后別的程序員都可以通過(guò)單元測(cè)試來(lái)理解一個(gè)系統(tǒng)的組成以及使用方法，并能夠很快的理解他們要做的工作以及在哪里切入。

單元測(cè)試命名

在單元測(cè)試的結(jié)構(gòu)中已經(jīng)有過(guò)要求和介紹。參考那部分。

單元測(cè)試中的變量命名

通過(guò)合理的命名變量，可以提高可讀性，使得閱讀測(cè)試的人員可以盡快的理解你要驗(yàn)證的內(nèi)容。
還是看看上面的例子

[Test]
public void TakeDamage_BeAttacked_HpEqual()
{
//Arrange
    HpComp health = new HpComp();
    health.currentHp = 100;
   //Act
    health.TakeDamage(50);
   //Assert
    Assert.AreEqual(50f, health.currentHp);
}

這段代碼中的斷言使用了一個(gè)魔數(shù)50，但是這個(gè)數(shù)字并沒(méi)有使用描述性的名字，因此我們無(wú)法盡快的知道這個(gè)數(shù)字預(yù)期的是什么。因此，我們盡可能不要直接使用數(shù)字和結(jié)果比較，而是使用一個(gè)有意義命名的變量來(lái)和結(jié)果進(jìn)行比較。

[Test]
public void TakeDamage_BeAttacked_HpEqual()
{
    HpComp health = new HpComp();
    health.currentHp = 100;

    health.TakeDamage(50);

    float leftHp = 50f;

    Assert.AreEqual(leftHp, health.currentHp);
}

0x07 在Untiy編輯器中寫(xiě)單元測(cè)試

在Unity編輯器中編寫(xiě)單元測(cè)試用例時(shí)，使用的主要是Unity編輯器自帶的單元測(cè)試模塊，因此單元測(cè)試是基于NUnit框架的。
這就要求編寫(xiě)單元測(cè)試時(shí)，要引入NUnit.Framework命名空間，且單元測(cè)試類(lèi)要加上[TestFixture]屬性，單元測(cè)試方法要加上[Test]屬性，并將測(cè)試用例的文件放在Editor文件夾下。
測(cè)試用例的編寫(xiě)結(jié)構(gòu)要遵循3A原則，即Arrange, Act, Assert。
即先要設(shè)置測(cè)試環(huán)境，例如實(shí)例化測(cè)試類(lèi)，為測(cè)試類(lèi)的字段賦值。
之后寫(xiě)測(cè)試的行為。
最后是判斷是否通過(guò)測(cè)試。
下面是一個(gè)例子：

using UnityEngine;
using System.Collections;
using NUnit.Framework;

[TestFixture]
public class HealthComponentTests
{
  //測(cè)試傷害之后，血的值是否比0大
  [Test]
  public void TakeDamage_BeAttacked_BiggerZero()
    {
      //Arrange 
      UnMonoHealthClass health = new UnMonoHealthClass();
      health.healthAmount = 50f;

      //Act
      health.TakeDamage(60f);

      //Assert
        Assert.GreaterOrEqual(health.healthAmount, 0);
    }
}

該例子是測(cè)試英雄受到傷害之后，血量是否會(huì)越界出現(xiàn)負(fù)值。
測(cè)試框架會(huì)創(chuàng)建這個(gè)測(cè)試用例類(lèi)，并且調(diào)用TakeDamage_BeAttacked_BiggerZero方法來(lái)和其交互，最后使用Nunit的Assert類(lèi)來(lái)斷言是否通過(guò)測(cè)試。

使用Editor Tests Runner開(kāi)始單元測(cè)試：

寫(xiě)完了單元測(cè)試用例之后，我們就可以在Unity5.3.x的editor中開(kāi)始單元測(cè)試了。如圖所示：

在這里，我們既可以跑單獨(dú)的測(cè)試用例，也可以跑所有的測(cè)試用例，通過(guò)的是綠色標(biāo)識(shí)，未通過(guò)的是紅色標(biāo)識(shí)。
而在最上面的一行，則是我們可以操作的部分：
Run All：測(cè)試全部用例
Run Selected：測(cè)試選中的用例
Rerun Failed： 重新測(cè)試上一次未通過(guò)的測(cè)試用例
搜索框：可以搜索用例
種類(lèi)過(guò)濾器：可以根據(jù)種類(lèi)來(lái)篩選用例。種類(lèi)需要在測(cè)試代碼中使用CategoryAttribute來(lái)標(biāo)識(shí)。
測(cè)試結(jié)果篩選器：可以按照通過(guò)、失敗以及忽略來(lái)篩選用例

使用命令行運(yùn)行單元測(cè)試：

除了能夠在Editor中使用單元測(cè)試，我們自然更希望能夠?qū)卧獪y(cè)試也納入自動(dòng)集成的流水線中，因此有必要從U3D外部調(diào)用測(cè)試。不過(guò)好在U3D也提供了外部調(diào)用的方式，這樣將單元測(cè)試也加入到我們的自動(dòng)集成的流水線中是可行的。
Unity3D 5.3.x版本中提供的命令行選項(xiàng)如下：

runEditorTests  必須，運(yùn)行editor test的選項(xiàng)
editorTestsResultFile 用來(lái)保存測(cè)試結(jié)果
editorTestsFilter 根據(jù)用例名稱(chēng)，來(lái)運(yùn)行指定的用例
editorTestsCategories 根據(jù)用例種類(lèi)，來(lái)運(yùn)行指定的用例
editorTestsVerboseLog 打印更加詳細(xì)的日志
projectPath 工程目錄
所以在命令行中開(kāi)啟測(cè)試可以這樣寫(xiě)：
Unity -runEditorTests -projectPath /Users/fanyou/UnitTest -editorTestsResultFile  /Users/fanyou/UnitTest/test.xml -batchmode -quit

0x08 后記

以上便是關(guān)于在U3D中引入單元測(cè)試的一些思考，當(dāng)然，游戲開(kāi)發(fā)是否適合TDD，換言之是否要先寫(xiě)單元測(cè)試后實(shí)現(xiàn)功能是值得討論的事情，但是單元測(cè)試本身是十分有必要在工程中使用的。在代碼結(jié)構(gòu)設(shè)計(jì)、日后的重構(gòu)都會(huì)很有幫助。

相關(guān)：

TDD在Unity3D游戲項(xiàng)目開(kāi)發(fā)中的實(shí)踐