2017年9月5日 星期二

Unity說明文件範例正確性檢測 - 玩轉Unity編輯器測試工具

作者:Karl Jones 原文
發表於: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選項來同時執行。


本範例使用CodeDomProvider 編譯,這樣可以傳遞多個表示腳本的字串,並編譯和返回相關的錯誤及警告資訊。
首次測試反覆運算的縮減版(已刪除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台灣官方部落格 請上Facebook搜尋Unity Taiwan取得Unity中文的最新資訊