0x00 單元測試Pro & Con
　　近嘗試在我參與的游戲項目中引入TDD（測試驅動開發(fā)）的開發(fā)模式，因此單元測試便變得十分必要。這篇博客來聊一聊這段時間的感悟和想法。由于游戲開發(fā)和傳統(tǒng)軟件開發(fā)之間的差異，因此在開發(fā)游戲，特別是使用Unity3D開發(fā)游戲的過程中編寫單元測試往往會面臨兩個主要的問題：
　　游戲開發(fā)中會涉及到很多的I/O操作處理，以及視覺和UI的處理，而這個部分是單元測試中比較難以處理的部分。
　　具體到使用Unity3D開發(fā)游戲，我們自然而然的希望能夠將測試的框架集成到Unity3D的編輯器中，這樣更加容易操作。
　　但是，單元測試的好處也十分多。
　　TDD，測試驅動開發(fā)。編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試，迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合�？梢詫⑷蝿盏牧６冉档�。當然TDD是否適合游戲開發(fā)尚有爭論，但是單元測試的必要性是無需置疑的。
　　單元測試是一種無價的文檔，它是展示方法或類如何使用的佳文檔。這份文檔是可編譯、可運行的，并且它保持新，永遠與代碼同步。
　　更加適合應對需求的經(jīng)常性變更。身處游戲開發(fā)行業(yè)的從業(yè)人員都不能否認的一點便是游戲開發(fā)中需求變更是一件不可避免甚至是必不可少的事情，而單元測試另一個好處便是一旦因為需求變更而出現(xiàn)bug，能夠很快的發(fā)現(xiàn)，進而解決問題。
　　0x01 Unity3D中常用的測試工具
　　針對問題1，由于對I/O處理以及UI視覺方面的操作比較難以實施單元測試，所以我們單元測試的主要對象是邏輯操作以及數(shù)據(jù)存取的部分。
　　針對問題2，Unity5.3.x已經(jīng)在editor中集成了測試模塊。該測試模塊依托了NUnit框架（NUnit是一個單元測試框架，專門針對于.NET來寫的.其實在前面有JUnit(Java)，CPPUnit(C++)，他們都是xUnit的一員.初，它是從JUnit而來.U3d使用的版本是2.6.4）。
　　在Unity Editor中實現(xiàn)測試而不是在IDE中進行測試的原因在于，一些Unity的API需要在Unity的環(huán)境中來運行，而無法直接在外部的IDE中實現(xiàn)，例如實例化GameObject。
　　而且除了Unity5.3.x自帶的單元測試模塊之外，Unity官方還推出了一款測試插件Unity Test Tool（基于NSubstitute），除了單元測試之外還包括：
　　· 單元測試
　　· 集成測試
　　· 斷言組件
　　需要指出的是Unity Test Tool基于NSubstitute這個庫。
　　0x02 初識單元測試
　　既然本文的主題是單元測試，那么我們必須先對單元測試下一個定義：
　　一個單元測試是一段自動化的代碼，這段代碼調用被測試的工作單元，之后對這個單元的單個終結果的某些假設進行檢驗。單元測試使用單元測試框架編寫，并要求單元測試可靠、可讀并且可維護。只要產(chǎn)品代碼不發(fā)生變化，單元測試的結果是穩(wěn)定的。
　　既然有了單元測試的定義，下面我們嘗試在Unity項目中寫單元測試吧。
　　一個單元測試的小例子：
　　編寫單元測試用例時，使用的主要是Unity Editor自帶的單元測試模塊，因此單元測試是基于NUnit框架的。
　　借助NUnit，我們可以：
　　編寫結構化的測試。
　　自動執(zhí)行選中的或全部的單元測試。
　　查看測試運行的結果。
　　因此這要求編寫Unity3D項目的單元測試時，要引入NUnit.Framework命名空間，且單元測試類要加上[TestFixture]屬性，單元測試方法要加上[Test]屬性，并將測試用例的文件放在Editor文件夾下。
　　下面是一個例子：
using UnityEngine;
using System.Collections;
using NUnit.Framework;
[TestFixture]
public class HpCompTests
{
//測試被攻擊之后傷害數(shù)值是否和預期值相等
[Test]
public void TakeDamage_BeAttacked_HpEqual()
{
//Arrange
HpComp health = new HpComp();
health.currentHp = 100;
//Act
health.TakeDamage(50);
//Assert
Assert.AreEqual(50f， health.currentHp);
}
}
　　該例子是測試英雄受到傷害之后，血量是否和預期的相等。
　　測試框架會創(chuàng)建這個測試用例類，并且調用TakeDamage_BeAttacked_HpEqual方法來和其交互，后使用Nunit的Assert類來斷言是否通過測試。
　　0x03 單元測試的結構
　　通過上面的小例子，我們可以發(fā)現(xiàn)單元測試其實是有結構的。下面我們來具體分析一下：
　　使用NUnit提供的特性來標識測試代碼
　　NUnit使用C#的特性機制識別和加載測試。這些特性像是書簽，用來幫助測試框架識別哪些部分是需要調用的測試。
　　如果要使用NUnit的特性，我們需要在測試代碼中首先引入NUnit.Framework命名空間。
　　而NUnit運行器至少需要兩個特性才知道需要運行什么。
　　[TestFixture]：標識一個自動化NUnit測試的類。
　　[Test]：可以加在一個方法上，標識這個方法是一個需要調用的自動化測試。
　　當然，還有一些別的特性供我們使用，來方便我們更好的控制測試代碼，例如[Category]特性可以將測試分類、[Ignore]特性可以忽略測試。
　　常用的NUnit屬性見下表：
　　[SetUp]
　　[TearDown]
　　[TestFixture]
　　[Test]
　　[TestCase]
　　[Category]
　　[Ignore]
　　測試命名和布局標準
　　測試類的命名：
　　對應被測試項目中的一個類，創(chuàng)建一個名為[ClassName]Tests的類。
　　工作單元的命名：
　　對每個工作單元（測試），測試方法的方法名由三部分組成，并且按照如下規(guī)則命名：[被測試的方法名]_[測試進行的假設條件]_[對測試方法的預期]。
　　具體來說：
　　被測試的方法名
　　測試進行的假設條件，例如“登入失敗”、“無效用戶”、“密碼正確”。
　　對測試方法的預期：在測試場景指定的條件下，我們對被測試方法的行為的預期。
　　其中，對測試方法的預期會有三種可能的結果：
　　返回一個值（數(shù)值、布爾值等等）。
　　改變被測試的系統(tǒng)的一個狀態(tài)。
　　調用一個第三方系統(tǒng)。
　　可以看出，我們的測試代碼在格式上與標準的代碼有所不同，測試名可以很長，但是在編寫測試代碼時，可讀性是為重要的方面之一，而測試名中的下劃線可以令我們不會遺漏所有的重要信息，我們甚至可以將測試方法名當做一個句子來讀，這樣會使得這個測試方法的測試目標、場景以及預期都十分明確，無需額外的注釋。
　　測試單元的行為——3A原則
　　有了NUnit屬性可以標識可以自動運行的測試代碼和測試代碼的一些命名規(guī)則，下面我們來看看如何測試自己的代碼。
　　一個單元測試通常包含三個行為，可以歸納為3A原則即：
　　Arrange，準備對象，創(chuàng)建對象并進行必要的設置。
　　Act，操作對象。
　　Assert，斷言某件事情是預期的。
　　下面是之前的那段簡單的代碼，包含了以上的NUnit的屬性、命名規(guī)范以及3A原則下的行為，其中斷言部分使用了NUnit框架提供的Assert類，被測試的類為HpComp，被測試的方法為
TakeDamage。
using NUnit.Framework;
[TestFixture]
public class HpCompTests
{
//測試被攻擊之后傷害數(shù)值是否和預期值相等
[Test]
public void TakeDamage_BeAttacked_HpEqual()
{
//Arrange
HpComp health = new HpComp();
health.currentHp = 100;
//Act
health.TakeDamage(50);
//Assert
Assert.AreEqual(50f， health.currentHp);
}
}
　　單元測試的斷言——Assert類
　　NUnit框架提供了一個Assert類來處理斷言的相關功能。Asset類用于聲明某個特定的假設應該成立，因此如果傳遞給Assert類的參數(shù)和我們斷言（預期）的值不同，則NUnit框架會認為測試沒有通過。
　　Assert類會提供一些靜態(tài)方法，供我們使用。
　　例如：
　　Assert.AreEqual(預期值，實際值)；
　　Assert.AreEqual(1，2 - 1)；
　　關于Assert類的靜態(tài)方法，各位可以直接在代碼中看。