0x04 單元測試的可靠性
我們的目標是寫出可靠、可維護、可讀的測試。
因此，除了遵循單元測試結構規范編寫單元測試之外，我們還需要注意可靠性、可維護性以及可讀性這些方面。因此，一些原則我們也需要注意。
不輕易刪除和修改測試
一旦測試寫好了并且通過了，不應該輕易的修改和刪除這些測試。因為這些測試是對應系統代碼的保護傘，在修改系統代碼時，這些測試會告訴我們修改后的代碼是否會破壞已有的功能。
盡量避免測試中的邏輯
隨著測試中的邏輯增多，測試代碼出現缺陷的幾率也會增大。而且由于我們往往相信測試是可靠的，因此一旦測試出現缺陷我們往往不會首先考慮是測試的問題，可能會浪費時間去修改系統代碼。而單元測試中，好保持邏輯的簡單，因此盡量避免使用下面的邏輯控制代碼。
switch、if
foreach、for、while
一個單元測試應該是一系列的方法調用和斷言，但是不應該包含控制流語句。
只測試一個關注點
在一個單元測試中驗證多個關注點會使得測試代碼變得復雜，但卻沒有價值。相反，我們應該在分開的、獨立的單元中驗證多余的關注點，這樣才能發現真正導致失敗的地方。
0x05 單元測試的可維護性
去除重復代碼
和系統中的重復代碼一樣，在單元測試中重復代碼同樣意味著測試對象某方面改變時要修改更多的測試代碼。
如果測試看上去都一樣，僅僅是參數不同，那么我們完全可以使用參數化測試即使用[TestCase]特性將不同的數據作為參數傳入測試方法。
實施測試隔離
所謂的測試隔離，指的是一個測試和其他的測試隔離，甚至不知道其他測試的存在，而只在自己的小世界中運行。
將測試隔離的目的是防止測試之間的互相影響，常見的測試之間互相影響的情況可以總結如下：
強制的測試順序：測試要以某種順序執行，后一個測試需要前面的測試結果，這種情況有可能會導致問題的原因是因為NUnit不能保證測試按照某種特定的順序執行，因此通過的測試，明天可能不好用了
隱藏的測試調用：測試調用其他測試
共享狀態被破壞：測試要共享狀態，但是在一個測試完成之后沒有重置狀態，進而影響后面的測試
0x06 單元測試的可讀性
正如概述中所說單元測試是一種無價的文檔，它是展示方法或類如何使用的佳文檔。因此，可讀性這條要求的重要性便可見一斑。試想一下即便是幾個月之后別的程序員都可以通過單元測試來理解一個系統的組成以及使用方法，并能夠很快的理解他們要做的工作以及在哪里切入。
單元測試命名
在單元測試的結構中已經有過要求和介紹。參考那部分。
單元測試中的變量命名
通過合理的命名變量，可以提高可讀性，使得閱讀測試的人員可以盡快的理解你要驗證的內容。
還是看看上面的例子
[Test]
public void TakeDamage_BeAttacked_HpEqual()
{
//Arrange
HpComp health = new HpComp();
health.currentHp = 100;
//Act
health.TakeDamage(50);
//Assert
Assert.AreEqual(50f， health.currentHp);
}
這段代碼中的斷言使用了一個魔數50，但是這個數字并沒有使用描述性的名字，因此我們無法盡快的知道這個數字預期的是什么。因此，我們盡可能不要直接使用數字和結果比較，而是使用一個有意義命名的變量來和結果進行比較。
[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文件夾下。
測試用例的編寫結構要遵循3A原則，即Arrange， Act， Assert。
即先要設置測試環境，例如實例化測試類，為測試類的字段賦值。
之后寫測試的行為。
后是判斷是否通過測試。
下面是一個例子：
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);
}
}
該例子是測試英雄受到傷害之后，血量是否會越界出現負值。
測試框架會創建這個測試用例類，并且調用TakeDamage_BeAttacked_BiggerZero方法來和其交互，后使用Nunit的Assert類來斷言是否通過測試。
使用Editor Tests Runner開始單元測試：
寫完了單元測試用例之后，我們可以在Unity5.3.x的editor中開始單元測試了。如圖所示：
在這里，我們既可以跑單獨的測試用例，也可以跑所有的測試用例，通過的是綠色標識，未通過的是紅色標識。
而在上面的一行，則是我們可以操作的部分：
Run All：測試全部用例
Run Selected：測試選中的用例
Rerun Failed： 重新測試上一次未通過的測試用例
搜索框：可以搜索用例
種類過濾器：可以根據種類來篩選用例。種類需要在測試代碼中使用CategoryAttribute來標識。
測試結果篩選器：可以按照通過、失敗以及忽略來篩選用例
在這里我們還可以設置在編譯前自動運行單元測試。
使用命令行運行單元測試：
除了能夠在Editor中使用單元測試，我們自然更希望能夠將單元測試也納入自動集成的流水線中，因此有必要從U3D外部調用測試。不過好在U3D也提供了外部調用的方式，這樣將單元測試也加入到我們的自動集成的流水線中是可行的。
Unity3D 5.3.x版本中提供的命令行選項如下：
runEditorTests 必須，運行editor test的選項
editorTestsResultFile 用來保存測試結果
editorTestsFilter 根據用例名稱，來運行指定的用例
editorTestsCategories 根據用例種類，來運行指定的用例
editorTestsVerboseLog 打印更加詳細的日志
projectPath 工程目錄
所以在命令行中開啟測試可以這樣寫：
Unity -runEditorTests -projectPath /Users/fanyou/UnitTest -editorTestsResultFile /Users/fanyou/UnitTest/test.xml -batchmode -quit
0x08 后記
以上便是關于在U3D中引入單元測試的一些思考，當然，游戲開發是否適合TDD，換言之是否要先寫單元測試后實現功能是值得討論的事情，但是單元測試本身是十分有必要在工程中使用的。在代碼結構設計、日后的重構都會很有幫助。。
