Android、JUnit深入淺出（七）——總結篇

 

在學習Android、JUnit的過程中，隨著學習的深入，將Android、JUnit的類按照繼承關係整理如下：

• Test—TestCase—AndroidTestCase
• Test—TestCase—InstrumentationTestCase
• Test—TestSuite—InstrumentationTestSuite
• TestListener——BaseTestRunner—AndroidTestRunner
• Instrumentation—InstrumentationTestRunner

上面的5條路線，也是我們不斷學習的過程，對於前4條路線感覺自己解析的都比較清楚，最後一條路線似乎說的不是很清楚，後來我又查看了不少這方面的資料，對Instrumentation再次說明下。

每個Android 應用程式運行在自己的進程，Instrumentation殺死當前應用程式，並重新啟動應用程式（restarts the process with Instrumentation）。Instrumentation提供給我們一個應用程式內容相關的Handle，通過這個Handle我們可以洞察應用程式，從而驗證測試斷言，我們還可以通過它來寫一些比介面測試更加底層的測試案例。需要強調說明的是：Instrumentation不能捕獲UI方面的bugs。

Android在JUnit的基礎上擴充出來的、與Instrumentation有關的3個類:

類	描述
InstrumentationTestCase	它擴充了JUnit中的TastCase，並提供了一個介面getInstrumentation() 擷取Instrumentation類。這個可以根據自己的需求來擴充這個類，比如說：測試中可能會啟動某個Avtivity和發送按鍵事件，為此完成測試，instrumentation需要將其注入到TastCase中。
InstrumentationTestRunner	它是Instrumentation的基礎上擴充的，它將自己注入到每個測試案例本身，測試案例需要分組到一個適當的InstrumentationTestRunner運行起來。
InstrumentationTestSuite	它擴充了JUnit TestSuite，其主要作用是保證每個TestCase在運行前，Instrumentation能注入到TestCase中，InstrumentationTestRunner中需要使用InstrumentationTestSuite。

以上說明來自網頁Instrumentation Testing（英文的），在這裡推薦給大家閱讀。

JUnit的使用心得

JUnit是採用測試驅動開發的方式，也就是說在開發前先寫好測試代碼，主要用來說明被測試的代碼會被如何使用，錯誤處理等；然後開始寫代碼，並在測試代碼中逐步測試這些代碼，直到最後在測試代碼中完全通過。

看了是否感覺有些不符合程式員的思維習慣（先寫代碼然後在調試），的確這也是JUnit是對程式員思維習慣的“顛覆”。在這裡我自己也感覺，好像很難做到，為什嗎？在一匹“馬”沒有完全設計好前，怎麼規定這匹“馬”將來會如何跑？而且即使把“馬”將來會如何“跑”定義好了，在實現的時候“馬”被改變了怎麼辦？說到底還是：一個人不能同時具有2個角色，否則自己有時候就不知道當前是哪個角色！

說到這裡，我就說明下，我自己對JUnit “錯誤”的使用方法，這也許與JUnit測試驅動開發的目的相矛盾，但是的確可以有效地減少bug。JUnit從核心來說就是將原始碼與測試代碼完全分開，將測試代碼作為一個單獨的程式。前面介紹的方法，都將原始碼與測試代碼合為一體，由於原始碼的重要性大於測試代碼的重要性，所以測試代碼經常有不完整、結構不清晰等問題，這樣程式員的單元測試也就不完整。JUnit就是被我用來做完整的單元測試，對當前的部分代碼，測試其在每種“環境”下的運行結果。

後記說明

曆時半個月的學習，總算把Android、JUnit深入解析篇寫完了，還是比較全面的介紹了Android中使用JUnit的方方面面，在寫部落格的過程中，我也盡量把自己遇到的每個問題，在這裡與大家分享，並盡量把每個問題解析清楚。如果你看了之後，感覺有什麼不足、錯誤、遺漏的地方，歡迎大家在部落格中留言。