發表於:2017/8/18
潤稿:Kelvin Lo
每當我遇到不熟悉的API，當下第一反應一定是去查查Unity文件，看看文件裡的範例來瞭解API的使用方式。但如果按照文件依樣畫葫蘆卻編譯失敗的話，是否可能是文件出錯了呢？
這是Unity Hackweek(註一)的一個專案，利用Unity 5.3以上的編輯器測試工具，來自動檢驗所有Unity腳本的範例程式是否編譯成功。
Unity腳本文件共有15000頁左右，其中並非所有文件都包含範例（這需要另外解決），但也已經不少了。手動檢查每個範例加上測試，在為期一周的Hackweek中很難辦到，也無法解決未來的API更新衍伸的文件更新問題。
然而去年發佈的Unity 5.3中包含一個新功能：Editor Test Runner，它是能在Unity中執行的單元測試框架(unit test framework)。這個功能發佈後就一直用於Unity內部測試，幫助我們追蹤問題。Unity所有腳本文件都保存為XML檔，可以在Unity內部專案中編輯。
專案已經包含解析XML檔的程式，所以只需在專案中加上編輯器測試即可使用這些功能。在編輯器測試框架中會用到TestCaseSource屬性，讓測試多次在不同的來源資料上執行。在本例中，來源資料就是程式範例文件：
這個方法會顯示所有執行在Test Runner上的測試。每個測試都能獨立執行，或通過Run ALL選項來同時執行。
這是Unity Hackweek(註一)的一個專案，利用Unity 5.3以上的編輯器測試工具，來自動檢驗所有Unity腳本的範例程式是否編譯成功。
Unity腳本文件共有15000頁左右，其中並非所有文件都包含範例（這需要另外解決），但也已經不少了。手動檢查每個範例加上測試，在為期一周的Hackweek中很難辦到，也無法解決未來的API更新衍伸的文件更新問題。
然而去年發佈的Unity 5.3中包含一個新功能：Editor Test Runner，它是能在Unity中執行的單元測試框架(unit test framework)。這個功能發佈後就一直用於Unity內部測試，幫助我們追蹤問題。Unity所有腳本文件都保存為XML檔，可以在Unity內部專案中編輯。
專案已經包含解析XML檔的程式，所以只需在專案中加上編輯器測試即可使用這些功能。在編輯器測試框架中會用到TestCaseSource屬性，讓測試多次在不同的來源資料上執行。在本例中，來源資料就是程式範例文件：
這個方法會顯示所有執行在Test Runner上的測試。每個測試都能獨立執行，或通過Run ALL選項來同時執行。
本範例使用CodeDomProvider 編譯，這樣可以傳遞多個表示腳本的字串，並編譯和返回相關的錯誤及警告資訊。
首次測試反覆運算的縮減版（已刪除XML解析）：
運作很正常! 編譯腳本的方式還需做些調整，因為有些腳本是組合在一起的方式形成一個範例。分別編譯所有範例以檢測是否有這種情況，如果出現錯誤再將其合併編譯，看看是否成功。
還有一些簡單範例就是一行程式，沒有封裝在函數內。可以在測試中進行封裝來處理這種問題，要遵循的規則就是這些例子必須能獨立執行（即開發者將它複製貼上到一個新的檔案中也可以被編譯和執行），否則就將這些範例視為測試失敗。
這個測試方法現在離正式作為文檔驗證工具還有一段距離。我還需要解決一個小問題：這個測試流程執行需花費30分鐘。由於我們每天需要執行約7000個版本，僅僅作為一個版本驗證測試來說這個執行時間太長了。
目前這個測試方法是依序執行的，一次一個腳本。由於測試彼此獨立，且無需呼叫Unity API，因為只測試編譯是否成功，所以完全可以並行執行這些測試。下面引入用於並存執行任務的.NET API-執行緒池。將測試作為單個任務放入執行緒池中，當執行緒可用時立即執行。這需要從單個函數執行，即不能用單獨的NUnit測試用範例來測試文件的單一範例。儘管不能單獨測試，但我們大大提高了整體執行的速度。
這將測試時間從30分鐘縮短至2分鐘，作為版本驗證來說已滿足需求。由於無法測試單個範例，所以在腳本文件編輯器中加入按鈕，以便文件編寫人員日後更新。執行測試時出錯腳本會顯示為紅色，並在下方顯示錯誤資訊。
首次執行測試時有326個錯誤，將這些加入白名單以便日後更新。畫面現在只剩32個，大多錯誤都是由於無法存取特定的程式集導致。整合該測試並未引入新的問題，所以可以確定如果棄用部分API導致測試失敗，則需要更新文件來使用新的API。
首次測試反覆運算的縮減版（已刪除XML解析）：
運作很正常! 編譯腳本的方式還需做些調整，因為有些腳本是組合在一起的方式形成一個範例。分別編譯所有範例以檢測是否有這種情況，如果出現錯誤再將其合併編譯，看看是否成功。
還有一些簡單範例就是一行程式，沒有封裝在函數內。可以在測試中進行封裝來處理這種問題，要遵循的規則就是這些例子必須能獨立執行（即開發者將它複製貼上到一個新的檔案中也可以被編譯和執行），否則就將這些範例視為測試失敗。
這個測試方法現在離正式作為文檔驗證工具還有一段距離。我還需要解決一個小問題：這個測試流程執行需花費30分鐘。由於我們每天需要執行約7000個版本，僅僅作為一個版本驗證測試來說這個執行時間太長了。
目前這個測試方法是依序執行的，一次一個腳本。由於測試彼此獨立，且無需呼叫Unity API，因為只測試編譯是否成功，所以完全可以並行執行這些測試。下面引入用於並存執行任務的.NET API-執行緒池。將測試作為單個任務放入執行緒池中，當執行緒可用時立即執行。這需要從單個函數執行，即不能用單獨的NUnit測試用範例來測試文件的單一範例。儘管不能單獨測試，但我們大大提高了整體執行的速度。
這將測試時間從30分鐘縮短至2分鐘，作為版本驗證來說已滿足需求。由於無法測試單個範例，所以在腳本文件編輯器中加入按鈕，以便文件編寫人員日後更新。執行測試時出錯腳本會顯示為紅色，並在下方顯示錯誤資訊。
首次執行測試時有326個錯誤，將這些加入白名單以便日後更新。畫面現在只剩32個，大多錯誤都是由於無法存取特定的程式集導致。整合該測試並未引入新的問題，所以可以確定如果棄用部分API導致測試失敗，則需要更新文件來使用新的API。
結語
本文只是Editor Test Runner工具一個非常有趣的使用案例，當然還有待改進，例如只能抓取C#範例，無法處理.js的編譯。但在不久的將來，這也將不再是問題。(註二)
感謝各位，完整程式碼可以從原文最後面取得。
<註一> Unity Hackweek是一個Unity內部活動，每年研發人員會集合並討論Unity有哪些需要改進的地方，並在為期一周的時間，動手做個初始原型，有點像是企業內部的黑客松。
<註二> Unity已經對外發佈未來即將不支援 Unity Java Script。會專心維護C#。
<註一> Unity Hackweek是一個Unity內部活動，每年研發人員會集合並討論Unity有哪些需要改進的地方，並在為期一周的時間，動手做個初始原型，有點像是企業內部的黑客松。
程式碼貌似消失了，請問可以幫忙補一份嗎 謝謝
回覆刪除很抱歉，原作者已經把連結移除，但在原文的最後面他也修改了部分內容，有貼上他的程式碼。
刪除