0x04 單元測試的可靠性
　　我們的目標(biāo)是寫出可靠、可維護、可讀的測試。
　　因此，除了遵循單元測試結(jié)構(gòu)規(guī)范編寫單元測試之外，我們還需要注意可靠性、可維護性以及可讀性這些方面。因此，一些原則我們也需要注意。
　　不輕易刪除和修改測試
　　一旦測試寫好了并且通過了，不應(yīng)該輕易的修改和刪除這些測試。因為這些測試是對應(yīng)系統(tǒng)代碼的保護傘，在修改系統(tǒng)代碼時，這些測試會告訴我們修改后的代碼是否會破壞已有的功能。
　　盡量避免測試中的邏輯
　　隨著測試中的邏輯增多，測試代碼出現(xiàn)缺陷的幾率也會增大。而且由于我們往往相信測試是可靠的，因此一旦測試出現(xiàn)缺陷我們往往不會首先考慮是測試的問題，可能會浪費時間去修改系統(tǒng)代碼。而單元測試中，好保持邏輯的簡單，因此盡量避免使用下面的邏輯控制代碼。
　　switch、if
　　foreach、for、while
　　一個單元測試應(yīng)該是一系列的方法調(diào)用和斷言，但是不應(yīng)該包含控制流語句。
　　只測試一個關(guān)注點
　　在一個單元測試中驗證多個關(guān)注點會使得測試代碼變得復(fù)雜，但卻沒有價值。相反，我們應(yīng)該在分開的、獨立的單元中驗證多余的關(guān)注點，這樣才能發(fā)現(xiàn)真正導(dǎo)致失敗的地方。
　　0x05 單元測試的可維護性
　　去除重復(fù)代碼
　　和系統(tǒng)中的重復(fù)代碼一樣，在單元測試中重復(fù)代碼同樣意味著測試對象某方面改變時要修改更多的測試代碼。
　　如果測試看上去都一樣，僅僅是參數(shù)不同，那么我們完全可以使用參數(shù)化測試即使用[TestCase]特性將不同的數(shù)據(jù)作為參數(shù)傳入測試方法。
　　實施測試隔離
　　所謂的測試隔離，指的是一個測試和其他的測試隔離，甚至不知道其他測試的存在，而只在自己的小世界中運行。
　　將測試隔離的目的是防止測試之間的互相影響，常見的測試之間互相影響的情況可以總結(jié)如下：
　　強制的測試順序：測試要以某種順序執(zhí)行，后一個測試需要前面的測試結(jié)果，這種情況有可能會導(dǎo)致問題的原因是因為NUnit不能保證測試按照某種特定的順序執(zhí)行，因此通過的測試，明天可能不好用了
　　隱藏的測試調(diào)用：測試調(diào)用其他測試
　　共享狀態(tài)被破壞：測試要共享狀態(tài)，但是在一個測試完成之后沒有重置狀態(tài)，進而影響后面的測試
　　0x06 單元測試的可讀性
　　正如概述中所說單元測試是一種無價的文檔，它是展示方法或類如何使用的佳文檔。因此，可讀性這條要求的重要性便可見一斑。試想一下即便是幾個月之后別的程序員都可以通過單元測試來理解一個系統(tǒng)的組成以及使用方法，并能夠很快的理解他們要做的工作以及在哪里切入。
　　單元測試命名
　　在單元測試的結(jié)構(gòu)中已經(jīng)有過要求和介紹。參考那部分。
　　單元測試中的變量命名
　　通過合理的命名變量，可以提高可讀性，使得閱讀測試的人員可以盡快的理解你要驗證的內(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);
　　}
　　這段代碼中的斷言使用了一個魔數(shù)50，但是這個數(shù)字并沒有使用描述性的名字，因此我們無法盡快的知道這個數(shù)字預(yù)期的是什么。因此，我們盡可能不要直接使用數(shù)字和結(jié)果比較，而是使用一個有意義命名的變量來和結(jié)果進行比較。
　　[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編輯器中寫單元測試
　　在Unity編輯器中編寫單元測試用例時，使用的主要是Unity編輯器自帶的單元測試模塊，因此單元測試是基于NUnit框架的。
　　這要求編寫單元測試時，要引入NUnit.Framework命名空間，且單元測試類要加上[TestFixture]屬性，單元測試方法要加上[Test]屬性，并將測試用例的文件放在Editor文件夾下。
　　測試用例的編寫結(jié)構(gòu)要遵循3A原則，即Arrange， Act， Assert。
　　即先要設(shè)置測試環(huán)境，例如實例化測試類，為測試類的字段賦值。
　　之后寫測試的行為。
　　后是判斷是否通過測試。
　　下面是一個例子：
using UnityEngine;
using System.Collections;
using NUnit.Framework;
[TestFixture]
public class HealthComponentTests
{
//測試傷害之后，血的值是否比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);
}
}
　　該例子是測試英雄受到傷害之后，血量是否會越界出現(xiàn)負(fù)值。
　　測試框架會創(chuàng)建這個測試用例類，并且調(diào)用TakeDamage_BeAttacked_BiggerZero方法來和其交互，后使用Nunit的Assert類來斷言是否通過測試。
　　使用Editor Tests Runner開始單元測試：
　　寫完了單元測試用例之后，我們可以在Unity5.3.x的editor中開始單元測試了。如圖所示：

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

　　在這里我們還可以設(shè)置在編譯前自動運行單元測試。
　　使用命令行運行單元測試：
　　除了能夠在Editor中使用單元測試，我們自然更希望能夠?qū)�單元測試也納入自動集成的流水線中，因此有必要從U3D外部調(diào)用測試。不過好在U3D也提供了外部調(diào)用的方式，這樣將單元測試也加入到我們的自動集成的流水線中是可行的。
　　Unity3D 5.3.x版本中提供的命令行選項如下：
　　runEditorTests  必須，運行editor test的選項
　　editorTestsResultFile 用來保存測試結(jié)果
　　editorTestsFilter 根據(jù)用例名稱，來運行指定的用例
　　editorTestsCategories 根據(jù)用例種類，來運行指定的用例
　　editorTestsVerboseLog 打印更加詳細(xì)的日志
　　projectPath 工程目錄
　　所以在命令行中開啟測試可以這樣寫：
　　Unity -runEditorTests -projectPath /Users/fanyou/UnitTest -editorTestsResultFile  /Users/fanyou/UnitTest/test.xml -batchmode -quit
　　0x08 后記
　　以上便是關(guān)于在U3D中引入單元測試的一些思考，當(dāng)然，游戲開發(fā)是否適合TDD，換言之是否要先寫單元測試后實現(xiàn)功能是值得討論的事情，但是單元測試本身是十分有必要在工程中使用的。在代碼結(jié)構(gòu)設(shè)計、日后的重構(gòu)都會很有幫助。。