隨著 Agile 的普及以及開發(fā)人員對測試重要性的認識逐步加深，大連系統(tǒng)開發(fā)Android中的單元測試已經(jīng)成了越來越多軟件項目開發(fā)中不可缺少的一部分。無論項目是不是采用TDD的形式來進行開發(fā)，單元測試都能夠為項目的修改和重構(gòu)提供一定的保障。
Android作為主要的移動平臺之一，吸引了無數(shù)的開發(fā)人員。但面對Android平臺和環(huán)境的種種限制，很多開發(fā)人員往往有心無力，很難為項目添加全面有效的單元測試。
大連系統(tǒng)開發(fā)Android中的單元測試環(huán)境中集成了一個測試框架（Instrumented Test），用于支持其單元測試和驗收測試。Robotium同樣提供一個類似于Selenium的測試框架，使得開發(fā)人員可以對應(yīng)用的功能進行驗證。
致遠服軟認為：http://www.soft8.com.cn/這兩種方式提供的測試環(huán)境都類似于集成測試，它們的測試用例都需要在模擬器上運行，通過對模擬器的操作或者Mock，來觸發(fā)函數(shù)調(diào)用，進而對其結(jié)果進行驗證。這種方法通常粒度較大，測試的編寫和維護較為困難。而最為重要的是，由于測試需要運行于模擬器或測試機器上，我們在運行前需要將測試和應(yīng)用打包，進行部署安裝并最終在模擬器或測試機器的Delvik虛擬機上運行，其運行速度較普通的單元測試要慢許多，如果使用TDD來進行開發(fā)，根本無法達到快速開發(fā)的要求。
大連人臉對比識別軟件框架的測試用例都需要在模擬器中運行，是因為我們平時在開發(fā)時所使用的Andorid.jar是被精簡過的，只是用于日常開發(fā)。它只是一個placeholder，使得我們在開發(fā)時能夠不出編譯錯誤。它完全是一個Stub包，其中所有的類都只是Android平臺接口的一個Stub，如果在代碼中運行這個 Android.jar ，它們所有的方法都只會拋出一個 java.lang.RuntimeException （“Stub!”）異常。
所以，一旦測試代碼需要真正調(diào)用 Android 平臺相關(guān)的類或接口，它們就必須運行于真正實現(xiàn)了Android的環(huán)境，如模擬器或者是測試機器。
我們的另外一個選擇是只對 POJO 進行單元測試，如果遇到大連系統(tǒng)開發(fā)Android中的單元測試相關(guān)的代碼，就使用 Mock 框架對其進行模擬。這種方式一定程度上可以解決我們的問題，但這意味著我們需要大量地在測試環(huán)境中使用Mock和Stub。另外，雖然Android中界面的布局通常使用XML來實現(xiàn)，但項目的代碼中還是會存在各種對界面的操作和更新，UI和邏輯的耦合使測試更加不易。
即使這樣，由于Android平臺的復(fù)雜性（static方法，final方法和類，Context和Resources的管理），我們也很難對Android相關(guān)的代碼進行測試，以保證測試率。
那么如何能夠在不增加開發(fā)成本的情況下，有一個穩(wěn)定快速的單元測試環(huán)境呢？
