像google一樣測試系列之三：方案選型篇

三種測試模式預研

在測試代碼放在什麼位置上，及如何運行上， 經歷了如下過程：

最初模式：採用google官網單測模式：Local unit tests和Instrumented Tests。

但：組內希望與大組保持一致，即用testng，提供一個界面點擊後運行用例。同時是運行在業務app內。

因此，模式a誕生。

模式考慮：和開發代碼寫在同一目錄下，以不同package區分，同時新建測試activity界面供點擊運行用例，整體測試代碼編進開發代碼以app運行。

缺點：

（1）和業務耦合太大，業務app在打包時需要裁掉測試代碼和資源，和mainfest.xml中的測試元素。開發也不建議寫在一起；

（2）同時都能以命令行運行了，還要搞界面來點擊運行用例，感覺多此一舉；

（3）測試範圍上有些減少，比如 Android層的測試，Activity內一些private的邏輯的測試，則測試不了。非要測，就會變成觸發UI點擊來測，就變成了UI自動化了；

（4）與google單測理念不一致，一些google提供的測試庫不支持；

（5）調試不方便，每調試一次，都要打一次包，而打包耗時較久。

優點：

（1）測試代碼是在真的Android環境上執行；

（2）可以直接調用業務代碼和被測介面。

綜上，考慮到該模式，在測試範圍，業務代碼耦合，CI上，均不夠好，因此放棄。

希望繼續保持和大組一致，誕生了模式B。

模式考慮：因為目前小組內的產品，均是AS+gradle開發環境，而且AS+gradle也是行業趨勢。因此，新建module，類型為lib，測試代碼寫在module下，同時被業務module依賴，相當於手管插件方式。和業務代碼統一打成app，真機運行。

缺點：

1.、需要先運行業務app，才能觸發測試代碼，如果還需要和大組有界面點擊運行，仍然需要在業務代碼上 增加該代碼，也是有耦合，同時業務app在打包時，需要裁掉該代碼；

2、因為module只能是lib，因此被測介面要反射來調用，不能直接調用；

3、調試不方便；

4、業務打包，要裁掉該module；

5、測試範圍上同樣有些減少，比如 Android層的測試，Activity內一些private 的邏輯的測 試，同樣測試不了。

優點：

1、測試代碼剝離了，和業務耦合小了點。也可以不用界面點擊來運行；

2、測試運行環境為真Android環境。

綜上，考慮到該模式，在測試範圍，調試方便性，均不夠好，因此放棄。

最終還是回歸到了最初模式：Local Unit Tests和Instrumented Tests。

方案選型

在經過各模式的預研，實踐，選好測試模式後，選用什麼框架來測試也是個選擇。

考慮的是：Robolectric。

Robolectric樣例代碼：

綜上：

1、從Robolectric樣例代碼可以看出，目前Robolectric 基本是 從UI層介入，理論上可以忽略UI層，測試單一組件的邏輯，但關鍵的是不能測試組件的集成邏輯。

2、android層的測試也是運行在PC端的，它並不能測試業務app在真實Android環境上的表現。

因此，最終放棄了Robolectric，選擇了Local Unit Tests和Instrumented Tests。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！