mockitoandroid

㈠ android studio怎麼進行單元測試

注意：這里以mac下的操作為例子。
新建一個Android 工程，參考下圖的步驟。
1、填寫項目名稱："LocalUnitTestDemo"
2、選擇sdk版本，這里選擇api16，android 4.1
3、添加一個空的activity頁面，blank activity
4、確認添加的activity頁面名稱等。

工程建立好之後，切換項目到Project模式，mac下按『Command』+『1』可以看到新生成的代碼目錄結構。
"app/src/main/java",這個目錄下是放我們app的源代碼；
"app/src/test/java"，這個目錄下是放我們本地單元測試的源代碼。

注意：如果工程建立好之後提示：『failed to resolve：junit：junit：4.12』,如下圖1。
這時需要修改我們工程的build.gradle
打開左側的Project側邊欄，找到我們的工程build.gradle，圖2，修改紅框里的兩個"jcenter()"依賴庫為：
maven { url "http://jcenter.bintray.com/" }maven { url "http://repo1.maven.org/maven2/"}
這兩句話。結果如圖三：

4
打開我們模塊app的build.gradle,圖1，添加兩個依賴項：
testCompile 'org.mockito:mockito-core:1.10.19'
androidTestCompile 'org.hamcrest:hamcrest-library:1.1'

㈡ 進行單元測試時android模擬器會不會啟動

測試androidsdk 開發單元測試
在安卓模擬器或者真機上跑測試用例速度很慢。構建、部署、啟動app，通常需要花費一分鍾或者更久。這不是TDD（測試驅動開發）模式.Robolectric提供一種更好的方式。
可能你一直嘗試在java IDE中使用junit或者testng直接跑測試用例，但是一直報java.lang.RuntimeException: Stub!異常。
這個異常是因為在jdk中沒有android運行環境。而現在Robolectric這款android單元測試工具，模擬了android sdk中的jar包，可以直接在jvm中運行測試用例，這樣就大大節省了時間。一個Robolectric測試用例如下：
// Test class for MyActivity @RunWith(RobolectricTestRunner.class) public class MyActivityTest { @Test public void clickingButton_shouldChangeResultsViewText() throws Exception { Activity activity = Robolectric.buildActivity(MyActivity.class).create().get(); Button pressMeButton = (Button) activity.findViewById(R.id.press_me_button); TextView results = (TextView) activity.findViewById(R.id.results_text_view); pressMeButton.performClick(); String resultsText = results.getText().toString(); assertThat(resultsText, equalTo("Testing Android Rocks!")); } }

在安卓模擬器或者真機上跑測試用例速度很慢。構建、部署、啟動app，通常需要花費一分鍾或者更久。這不是TDD（測試驅動開發）模式.Robolectric提供一種更好的方式。
可能你一直嘗試在java IDE中使用junit或者testng直接跑測試用例，但是一直報java.lang.RuntimeException: Stub!異常。
這個異常是因為在jdk中沒有android運行環境。而現在Robolectric這款android單元測試工具，模擬了android sdk中的jar包，可以直接在jvm中運行測試用例，這樣就大大節省了時間。一個Robolectric測試用例如下：
// Test class for MyActivity
@RunWith(RobolectricTestRunner.class)
public class MyActivityTest {

@Test
public void clickingButton_shouldChangeResultsViewText() throws Exception {
Activity activity = Robolectric.buildActivity(MyActivity.class).create().get();

Button pressMeButton = (Button) activity.findViewById(R.id.press_me_button);
TextView results = (TextView) activity.findViewById(R.id.results_text_view);

pressMeButton.performClick();
String resultsText = results.getText().toString();
assertThat(resultsText, equalTo("Testing Android Rocks!"));
}
}

SDK，Resource和Native Method模擬
Robolectric可以處理控制項展示、資源載入和很多使用native C實現的真機上的其他功能。所以我們可以使用Robolectric來模擬真機上的大部分操作。我們可以很方便地獲取Robolectric的源碼，直接查看它的模擬機制，所以使用Robolectric，我們也可以模擬錯誤條件和一些真實的感測器信號。
脫離模擬器執行測試用例
Robolectric允許我們在項目工程中或者持續集成（CI如hudson、jenkins）中使用jvm來執行測試用例，所以就省掉了打包、安裝的過程，將測試用例的執行時間由分鍾級降到秒級。
不再需要Mock框架
使用一些Mock框架，如Mockito或者Android Mock等，可以模擬出android運行環境，達到和Robolectric相同的效果。這是一個有效的方法，但是使用這種方法寫出的測試用例，很多情況下就是開發代碼的反實現。
Robolectric的測試風格更偏向於黑盒測試，robolectric式的測試用例更加關注與app的表現，而不是android運行環境的實現，所以使用robolectric寫出的測試用例更有效。當然這也是看測試人員的喜好，如果喜歡可以同時使用Robolectric和mock框架。

㈢ Android單元測試之Mockito的使用

Mockito最大的特點是模擬依賴，

打樁的意思是對mock出來的對象進行操作，比如模擬返回值

比如
Calculator文件有方法

通過單元測試可以模擬更改返回值

輸出 hello,leory

doReturn主要是對無法用thenReturn的情況，比如返回值void

輸出 小明

通過 verify(T mock) 驗證發生的某些行為 。

舉個栗子
參數為 aynInt()

參數包含某個string

參考 Android單元測試(二)：Mockito框架的使用

㈣ as中的mockable-android-24.jar有用嗎

本地Unit Test由於使用Junit4，因此與Java中的單元測試區別不大，可以靈活的使用Mockito來模擬調用Android的API。同時Android Studio在構建APP時，也會自動生成一個MockableAndroid.jar來支持這一需求。
Instrument類型測試由於類庫較多，因此使用的Runner也有所不同

㈤ 如何一步步實現AndroidCI

一步步實現Android CI

Android上的CI構建鏈與其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying階段，每一個階段的Feedback的都保持對整個團隊透明。

2、添加Function Test

Android為大家提供了一套集成測試框架Android integration testing
framework。但此框架未集成Cucumber，這導致每增加一個Function Test都需要較大的開發和維護工作。這樣高成本的實現Function
Test將大大延緩開發進度，最終因為項目進度的原因導致Function Test被丟棄。產生這樣的後果那必然是不願意看到的。

目前Android平台下已經出現多種Functiong Testing測試工具，如Native Driver, Robotium,
Calabash等。在嘗試對比後，最終選擇了Calabash Android作為解決方案。Calabash
Android是Cucumber在Android平台的實現，使用Ruby書寫Function Test，並提供了一組操作Anadroid App元素的API。

3、添加UI Test

Android在新近退出了UI測試工具UIAutomator。此工具僅支持Android4.1及以上平台，鑒於目前市場上2.3和4.0版本仍佔主導的情況來看，目前還無法滿足大家的需要。另外應用該工具實現UI測試的開發成本還較高，筆者暫不推薦使用此工具，但應該關注其發展。

另外基於錄制回放機制的測試方法同樣可以進行UI測試。但錄制回放的方法在面對功能快速迭代時，維護工作會急劇增加，而這個維護成本可以說是很難承受的，所以在此也不會將這種測試方法集成至CI中。

目前來看Android中UI測試還無令人滿意的方法。若對UI成功比較看重，可以投入精力應用UIAutomator進行UI測試。

Best Practice:

*
將測試按照單元測試，組件測試，功能測試和系統測試進行劃分。單元測試應該在每次提交時觸發執行，其它的測試根據運行時間長短和重要程度可以每次提交觸發執行或者定時周期執行。

* 將運行較快的測試優先執行。

* 讓功能測試能夠重復執行。否則維護成本太高，會被舍棄。若是後台數據導致不可重復，可以將數據抽象成為數據集，在每次運行前進行重置。

* 書寫測試時每一個assert只做一種判斷，這樣可以明確每次測試的目的，並且可以快速定位測試失敗願意。

步驟 3：持續檢查持續檢查是對於代碼本身檢測和反饋。檢測主要通過對代碼靜態分析驗證代碼風格，編程規范，代碼復用，代碼語言中的Best Practice等多個維度的代碼質量。

Sonar作為一個開源的代碼質量檢測工具，涵蓋了7項代碼質量檢測方式。這充分滿足Android平台下對於代碼質量的檢測分析。Sonar分為兩部分一部分是代碼分析工具，另一部分是數據分析展示的Server。

Best Practice:

* 將測試覆蓋率，代碼分析結果透明化

* 持續降低代碼復雜度

* 持續的促進設計的演進

* 持續的維護代碼結構

* 持續減少代碼重復

步驟 4：持續部署

由於Android App採用用戶手動從Appstore自行下載安裝的方式發布，使得Android
App無法直接部署至用戶手機中。另外Appstore需要對於上線的App進行審核，不能持續進行Release。因而Android中持續部署將以持續發布可安裝包為目標。

在以上目的下，只需根據自身項目資源找到合適的安裝包管理工具即可。如本文採用Dropbox來管理所有安裝包。

Dropbox作為一個雲存儲平台，在Android終端設備上可以輕松下載存放在其中的文件，同時上傳安裝包也可以交由Dropbox自己完成。

步驟 5：持續反饋

反饋是所有改進的開始，必須要讓所有人獲取到他們所關心的反饋信息，才能實施改進。持續反饋的目的就是讓所有人都掌握項目健康狀況。項目所有人事實都是有意願知道項目當前的健康狀況的，那CI就應該將項目的情況做到透明，並將不同的反饋通知到各相關的成員。

CI不同階段產生了不同維度的反饋，如單元測試報告，測試覆蓋率等。本實踐中將這些反饋都透明的展示在項目首頁中。之所以沒有將這些反饋再以郵件的方式通知所有人，是因為團隊成員已經養成了查看CI的習慣。

如果說只給所有人發一封郵件說明項目狀況，那必然是告訴所有人「CI所有步驟是否都返回正確？」。這樣一個反饋，包含了編譯正確，所有測試通過，安裝包已經准備完畢等重要信息。有必要讓所有人都知道這個信息，特別是在CI執行失敗的時候。Jenkins自身已經提供一個簡單有效的透明化方法，以項目為藍色表示通過，紅色表示有步驟失敗。

反饋的通知方式有很多種，不一定要採用郵件通知的方式。可以尋找更加有趣的方式，如果播放音樂和設置警報燈。在每一次Build成功或失敗後都播放一段有趣的音樂，打開不同顏色的警報燈，這兩種方法都是是一種簡單有效的方式，可以讓項目所有人都獲取到最為關鍵的信息。

㈥ 如何在android源碼里設置mockito

它分成以下幾個步驟： 建立mock； 將mock和待測試的對象連接起來； 在mock上設置預期的返回值； 開啟replay模式，准備記錄實際發生的調用； 進行測試； 驗證測試結果，調用順序是否正確，返回值是否符合期望；

㈦ # mockito2 坑 集成使用 Caused by: org.mockito.exceptions.base.MockitoException:

解決方案 compile "org.mockito:mockito-android:2.+" 對應 androidTest
解決方案 compile "org.mockito:mockito-core:2.+" 對應 test
選一個 不能共存
問題描述:
github issues

㈧ Android Studio 2.1 Preview 有哪些更新內容

1. 支持Java 8 語言特性和新的 Jack compiler編譯器 更新了一個新的項目向導用於配置生成針對Android N 預覽版本的項目。

2. 支持Android Emulator 2.0 Beta，並且為Android N 預覽版本系統映像提供了最佳的性能。
   （溫馨提醒）
   Android Studio 2.1在開發Android N Preview 版本的時候也帶來了以下幾個問題：
   立即運行Instant Run 不能和Jack compiler編譯器兼容，所以如果使用Jack compiler 編譯器Instant Run則會設置為不可用 （如果不使用Java 8特性完全沒必要使用Jack compiler編譯器）。 那些可查看.class 文件的工具 （例如 JaCoCo， Mockito，和一些lint檢查） 目前與 Jack compiler 編譯器不兼容。 本地調試（LLDB）目前在 Android N Preview 版本下不能工作。