測試
這是 “使用 Android Studio 開發 Web 程序” 系列的最后一篇文章，接著前一篇調試的主題之后要進行的是測試。不是已經可以調試了? 調試就是在測試了啊? 還要研究什么? 有這樣疑問的人可以先參考一下這一篇文章。
研究的方向是希望能夠確認在 Android Studio 進行測試時，可以滿足下幾項測試上的需求：
- 自動化
不僅僅是在開發時能夠大幅減少測試這項工作的負擔，并且還要能夠把自動化延續到 CI 系統中，以便有效提升整體的開發工作品質。 - Code Coverage
作為測試完成度的一項指標，借以調整測試程序開發的策略、投入的成本及風險的控管。 - Data Driven
用來與測試的策略搭配以提升 Code Coverage，并且可以將造成系統運作問題的數據保留下來，成為一個收集系統問題的機制，成為回歸測試的基準之一。
在 Android Studio 里就已內建了對 JUnit 和 TestNG 的支持，所以只要按照這些 Framework 的規格寫好測試類，并且把文件存在對應 Module 的 src/test 文件夾之下，IDE 就會自動識別出來。IDE 也有提供對應的功能來簡化測試的產生程序，相關的細節可以參考官網的 Creating Tests 及 Creating Test Methods。
有了測試的程序，接下來要確認是否能夠達成自動化的需求。首先，要啟動測試的話，透過 IDE 就可以輕易的達成，運行的細節可以參考官網的 Creating Run/Debug Configuration for Tests 及 Performing Tests 的說明文件。測試的結果會直接顯示在 IDE 的介面上，但要先確定 “Show Statistics” 的選項是否開啟，否則只會看到運行后的輸出結果。要如何開啟 “Show Statistics” 選項可以參考官網 Viewing and Exploring Test Results 的說明文件。
由 Run/Debug Configuration 的設定畫面可以發現，和 Eclipse 相同，可以設定要運行測試的范圍。所以只要設定好適當的選項，即可在 IDE 中一鍵運行所有的測試來達成開發階段的測試自動化。與 CI 系統整合的部分，既然是 Gradle 的專案，當然是運行 test 或是有包含 test 的 Task 來達到目的，由相關的功能來看自動化的需求已經能夠滿足。
在編寫源代碼的系列文章中有提到，IDE 的介面上就可以直接運行 Gradle 專案的 Task，和在 Terminal 下指令相同，都會產生 HTML 格式的測試報告在對應 Module 的 build/reports/tests 文件夾下。但如果是在 Terminal 下指令則要自行用瀏覽器開啟測試報告的 HTML 檔，而使用 IDE 運行 Task 則可以在 IDE 中檢視測試的結果，并點選如下圖所示的 “Open Gradle test report” 圖標啟動并顯示測試報告的內容。
而與測試有著密切關連的 Code Coverage 需求，由于 Android Studio 內建就有整合了 Code Coverage 的功能，所以只要是屬于測試類型的 Configuration 項目都可以使用 “Run 'xxx' with Coverage” 的功能，如果不是測試類型的 Configuration 項目在 Toolbar 上的圖標會被 Disable。相關的操作細節可以參考官網的 Running with Coverage 及 Viewing Code Coverage Results 的說明文件。
最后一項需求是 Data Driven，在 Android Studio 所支持的 JUnit 和 TestNG 都有提供特定的方法來達成目的。但在這里有一個比較不一樣的選擇：Spock，對，就是那個尖耳朵、瓜呆頭的半 Vulcan 星人的名字。這是一個和 JUnit 相容的測試框架，也就是說可以無縫式地被整合在支持 JUnit 的 IDE 中，再說得白話一點就是可以在 Android Studio 里使用 JUnit 的 Configuration 項目運行 Spock 的測試程序、產出測試報告、運行 Code Coverage 等。
為什么為想要使用 Spock 來做為測試的框架？主要是長久以來軟件設計的生命周期里，需求和程序之間都有一道明顯的鴻溝，原因是主流的程序語言還沒有進化到可以使用自然語言來表達，所以就需要靠程序撰寫人員來轉譯，把需求文件中的文字轉成可運行的源代碼。就算是導入 TDD 來協助開發，源代碼可以透過先寫好的測試程序來檢查是否符合需求，然而目前的測試程序也還都是相同的程序語言所構成的，需求里描述的情境還是要再被轉一手。
轉換就會有出現落差的風險，但是 Spock 使用 BDD 的概念填補了需求文件和測試程序間的差距，讓測試案例可以不被大幅轉譯的情況下，在測試源代碼中以接近自然語言的語法來呈現 (可惜是當然地使用英文的語法)，使轉譯失真的風險有效地被降低。就 Spock 這項特色來說，可以讓文件和測試建立直接的關連并且用來驗證實作的結果，是相當具有吸引力的。當然，Spock 也可以使用 Data Driven 的方式來撰寫測試程序，而且能夠以更直覺的的式來建立測試時所需的數據。
Spock 的測試類別是以 Groovy 為基礎，要在原本是 Java 的 Module 上使用 Groovy 要先設定讓 Module 支持 Groovy，詳細的操作步驟可以參考官網的 Configuring Groovy-Based Frameworks 說明文件。并且在 build.gradle 里應該包含以下示范的內容：
dependencies {
testCompile 'org.codehaus.groovy:groovy-all:2.3.3'
testCompile 'org.spockframework:spock-core:0.7-groovy-2.0'
}
在使用 Data Driven 產出的測試報告時有一個要注意的細節，通常測試報告顯示的單位都是以測試項目為基準，但由于 Data Driven 是在一個單一的測試項目中重覆地輸入不同數據的方式來進行。在使用 Data Driven 產出的測試報告沒有辦法顯示每一個受測數據樣本的測試結果時，會造成閱讀報告時一個很大的困擾。因為使用的樣本數有可能成百上千組，當測試報告顯示某個項目測試失敗，但卻無法顯示造成失敗的數據樣本，甚至連失敗樣本組數都沒有的話，錯誤根本就無從定位，也沒有辦法被修正。
在 Spock 中提供了一個 @Unroll 的 Annotation，可以讓測試報告顯示的項目揭露到每一組數據樣本的層級。透過 Gradle 的 test Task 產出的報告檔就會根據這個 Annotation 調整內容，將原本以測試項目為單位改為以受測的樣本組為單位。
但在 Android Studio 里會有一個小狀況是，如果只單獨運行一個測試類別，在 Statistics 里可以檢視到每一組數據樣本的測試結果。當同時運行多個類別的測試，Statistics 檢視不到相同的結果。所以這時可能就不能使用 JUnit 的 Configuration 來運行測試，要改為 Gradle 的 Configuration，并且在瀏覽器中來檢視測試報告。
截至目前為止，研究的結果大致都符合原先設定的需求條件，所以可以暫時完全先放下 Eclipse，開開心心地使用 Android Studio 上工啰！
