目錄
什么是Unit Test
Android單元測驗分類
構建有效的單元測驗
本地測驗
儀器化測驗
Robolectric
自動執行界面測驗
測驗單個應用界面
Espresso 基本使用
使用 Espresso Intent 單獨測驗 Activity
其他
測驗多個應用界面
官方資料
什么是Unit Test
Unit Test即單元測驗,單元測驗是應用測驗策略中的基本測驗,通過針對代碼創建和運行單元測驗,您可以輕松驗證各個單元的邏輯是否正確,在每次構建后運行單元測驗可幫助您快速捕捉和修復由應用的代碼更改導致的軟體回歸,
測驗應用是應用開發程序中不可或缺的一部分,通過持續對應用運行測驗,您可以在公開發布應用之前驗證其正確性、功能行為和易用性,
測驗還會為您提供以下優勢:
- 快速獲得故障反饋,
- 在開發周期中盡早進行故障檢測,
- 更安全的代碼重構,讓您可以優化代碼而不必擔心回歸,
- 穩定的開發速度,幫助您最大限度地減輕技術負擔,
Android單元測驗分類
為了測驗 Android 應用,您通常會創建下面這些型別的自動化單元測驗:
- 本地測驗(Local tests): 只在本地機器JVM上運行,以最小化執行時間,這種單元測驗不依賴于Android框架,或者即使有依賴,也很方便使用模擬框架來模擬依賴,以達到隔離Android依賴的目的,模擬框架如google推薦的Mockito;
- 儀器化測驗(Instrumented tests): 在真機或模擬器上運行的單元測驗,由于需要跑到設備上,比較慢,這些測驗可以訪問儀器(Android系統)資訊,比如被測應用程式的背景關系,一般地,依賴不太方便通過模擬框架模擬時采用這種方式,
構建有效的單元測驗
本地測驗
根據單元有沒有外部依賴(如Android依賴、其他單元的依賴),將本地測驗分為兩類,首先看看沒有依賴的情況:
- 添加依賴,google官方推薦
dependencies {
//Required--JUnit 4 framework
testImplementation 'junit:junit:4.12'
}
- 單元測驗代碼存盤位置
事實上,AS已經幫我們創建好了測驗代碼存盤目錄,
app/src
├── androidTestjava (儀器化單元測驗、UI測驗)
├── main/java (業務代碼)
└── test/java (本地單元測驗)
- 創建測驗類
可以自己手動在相應目錄創建測驗類,AS也提供了一種快捷方式:選擇對應的類->將游標停留在類名上->按下ALT + ENTER->在彈出的彈窗中選擇Create Test

Note: 勾選setUp/@Before會生成一個帶@Before注解的setUp()空方法,tearDown/@After則會生成一個帶@After的空方法,
package com.example.hellounittest;
import ...
public class EmailValidatorTest {
@Test
public void isValidEmail() {
assertThat(EmailValidator.isValidEmail("name@email.com"), is(true));
}
}
上面的寫法已過時,如果您更愿意使用 junit.Assert 其他方法來比較預期結果與實際結果,也可以改用這些庫,比如:
package com.example.hellounittest;
import ...
public class EmailValidatorTest {
@Test
public void isValidEmail() {
assertTrue(EmailValidator.isValidEmail("name@email.com"));
}
}
- 運行測驗用例
- 運行單個測驗方法:選中@Test注解或者方法名,右鍵選擇Run;
- 運行一個測驗類中的所有測驗方法:打開類檔案,在類的范圍內右鍵選擇Run,或者直接選擇類檔案直接右鍵Run;
- 運行一個目錄下的所有測驗類:選擇這個目錄,右鍵Run,
- 運行前面測驗驗證郵箱格式的例子,測驗結果會在Run視窗展示,如下圖:

從結果可以清晰的看出,測驗的方法為 EmailValidatorTest 類中的 isValidEmail()方法,測驗狀態為passed,耗時12毫秒,
修改一下前面的例子,傳入一個非法的郵箱地址:
@Test
public void isValidEmail() {
assertTrue(EmailValidator.isValidEmail("#name@email.com"));
}

測驗狀態為failed,耗時19毫秒,同時也給出了詳細的錯誤資訊:在11行出現了斷言錯誤,
- 總結一些常用的JUnit注解
| Annotation | 描述 |
| @Test public void method() | 定義所在方法為單元測驗方法 |
| @Test (expected = Exception.class) public void method() | 測驗方法若沒有拋出Annotation中的Exception型別(子類也可以)->失敗 |
| @Test(timeout=100) public void method() | 性能測驗,如果方法耗時超過100毫秒->失敗 |
| @Before public void method()
| 這個方法在每個測驗之前執行,用于準備測驗環境(如: 初始化類,讀輸入流等),在一個測驗類中,每個@Test方法的執行都會觸發一次呼叫, |
| @After public void method() | 這個方法在每個測驗之后執行,用于清理測驗環境資料,在一個測驗類中,每個@Test方法的執行都會觸發一次呼叫, |
| @BeforeClass public static void method() | 這個方法在所有測驗開始之前執行一次,用于做一些耗時的初始化作業(如: 連接資料庫),方法必須是static |
| @AfterClass public static void method() | 這個方法在所有測驗結束之后執行一次,用于清理資料(如: 斷開資料連接),方法必須是static |
| @Ignore或者@Ignore("太耗時") public void method() | 忽略當前測驗方法,一般用于測驗方法還沒有準備好,或者太耗時之類的 |
| @FixMethodOrder(MethodSorters.NAME_ASCENDING) public class TestClass{} | 使得該測驗類中的所有測驗方法都按照方法名的字母順序執行,可以指定3個值,分別是DEFAULT、JVM、NAME_ASCENDING |
- 通過模擬框架模擬依賴,隔離依賴
前面驗證郵件格式的例子,本地JVM虛擬機就能提供足夠的運行環境,但如果要測驗的單元依賴了Android框架,比如用到了Android中的Context類的一些方法,本地JVM將無法提供這樣的環境,這時候模擬框架Mockito就派上用場了,
添加依賴
//Optional--Mockito framework(可選,用于模擬一些依賴物件,以達到隔離依賴的效果)
testImplementation 'org.mockito:mockito-core:2.19.0'
一個Context.getString(int)的測驗用例
package com.example.hellounittest;
import ...
@RunWith(MockitoJUnitRunner.class)
public class MockUnitTest {
private static final String FAKE_STRING = "AndroidUnitTest";
@Mock
private Context mMockContext;
@Test
public void readStringFromContext() {
//模擬方法呼叫的回傳值,隔離對Android系統的依賴
when(mMockContext.getString(R.string.app_name)).thenReturn(FAKE_STRING);
Assert.assertEquals(mMockContext.getString(R.string.app_name), FAKE_STRING);
when(mMockContext.getPackageName()).thenReturn("com.example.hellounittest");
System.out.println(mMockContext.getPackageName());
}
}

通過模擬框架Mockito,指定呼叫context.getString(int)方法的回傳值,達到了隔離依賴的目的,
儀器化測驗
在某些情況下,雖然可以通過模擬的手段來隔離Android依賴,但代價很大,這種情況下可以考慮儀器化的單元測驗,有助于減少撰寫和維護模擬代碼所需的作業量,
儀器化測驗是在真機或模擬器上運行的測驗,它們可以利用Android framework APIs 和 supporting APIs,如果測驗用例需要訪問儀器(instrumentation)資訊(如應用程式的Context),或者需要Android框架組件的真正實作(如Parcelable或SharedPreferences物件),那么應該創建儀器化單元測驗,由于要跑到真機或模擬器上,所以會慢一些,
- 配置
dependencies {
androidTestImplementation 'androidx.test.ext:junit:1.1.2'
androidTestImplementation 'androidx.test:runner:1.3.0'
androidTestImplementation 'androidx.test:rules:1.3.0'
}
android {
...
defaultConfig {
...
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}
}
- Example
這里舉一個操作SharedPreference的例子,這個例子需要訪問Context類以及SharedPreference的具體實作,采用模擬隔離依賴的話代價會比較大,所以采用儀器化測驗比較合適,
這是業務代碼中操作SharedPreference的實作
package com.example.hellounittest;
import ...
public class SharedPreferenceDao {
private SharedPreferences mSharedPreferences;
public SharedPreferenceDao(SharedPreferences sp) {
this.mSharedPreferences = sp;
}
public SharedPreferenceDao(Context context) {
this(context.getSharedPreferences("config", Context.MODE_PRIVATE));
}
public void put(String key, String value) {
SharedPreferences.Editor editor = mSharedPreferences.edit();
editor.putString(key, value);
editor.apply();
}
public String get(String key) {
return mSharedPreferences.getString(key, null);
}
}
創建儀器化測驗類(app/src/androidTest/java)
package com.example.hellounittest;
import ...
public class SharedPreferenceDaoTest {
private static final String TEST_KEY = "instrumentedTest";
private static final String TEST_VALUE = "儀器化測驗";
private SharedPreferenceDao mSpDao;
@Before
public void setUp() throws Exception {
mSpDao = new SharedPreferenceDao(App.getContext());
}
@Test
public void sharedPreferenceDaoWriteRead(){
mSpDao.put(TEST_KEY, TEST_VALUE);
Assert.assertEquals(TEST_VALUE, mSpDao.get(TEST_KEY));
}
}
運行方式和本地單元測驗一樣,這個程序會向連接的設備安裝apk,測驗結果將在Run視窗展示,如下圖:

通過測驗結果可以清晰看到狀態passed,通過am instrument命令運行instrumented測驗用例,該命令的一般格式:
am instrument [flags] <test_package>/<runner_class>
例如本例子中的實際執行命令:
adb shell am instrument -w -r -e debug false -e class 'com.example.hellounittest.SharedPreferenceDaoTest' com.example.hellounittest.test/androidx.test.runner.AndroidJUnitRunner
-w: 強制 am instrument 命令等待儀器化測驗結束才結束自己(wait),保證命令列視窗在測驗期間不關閉,方便查看測驗程序的log
-r: 以原始格式輸出結果(raw format)
-e: 以鍵值對的形式提供測驗選項,例如 -e debug false
關于這個命令的更多資訊請參考
https://developer.android.com/studio/test/command-line?hl=zh-cn

這里可以看出,這個程序向模擬器安裝了兩個apk檔案,分別是HelloUnitTest和com.example.hellounittest.test,instrumented測驗相關的邏輯在com.example.hellounittest.test中,最新版中,google對儀器化測驗進行了很大的優化,從命令上來看是直接通過am instrument命令運行instrumented測驗用例,感受不到兩個apk的安裝程序,速度上有了大大的提升,如果業務邏輯足夠復雜,那么儀器化測驗仍然會非常耗時,如果你實在沒法忍受instrumented test的耗時問題,業界也提供了一個現成的方案Robolectric,
Robolectric
主要是解決儀器化測驗中耗時的缺陷,儀器化測驗需要安裝以及跑在Android系統上,也就是需要在Android虛擬機或真機上面,所以十分的耗時,基本上每次來來回回都需要幾分鐘時間,針對這類問題,業界其實已經有了一個現成的解決方案: Pivotal實驗室推出的Robolectric,通過使用Robolectrict模擬Android系統核心庫的Shadow Classes的方式,我們可以像寫本地測驗一樣寫這類測驗,并且直接運行在作業環境的JVM上,十分方便,
- 添加配置
testImplementation 'org.robolectric:robolectric:4.2.1'
android {
...
testOptions {
unitTests {
includeAndroidResources = true
}
}
}
- Example
模擬打開MainActivity,點擊界面上面的Button,讀取TextView的文本資訊,
以下是MainAcitivity代碼
package com.example.hellounittest;
import ...
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
final TextView textView = findViewById(R.id.textView);
Button button = findViewById(R.id.button);
button.setOnClickListener(v -> textView.setText("Robolectric Rocks!"));
}
}
測驗類MainActivityTest(注意這個測驗類是放在app/src/test/java/目錄下的,因為這是一段本地測驗代碼)
package com.example.hellounittest;
import ...
@RunWith(RobolectricTestRunner.class)
public class MainActivityTest {
@Test
public void clickingButtonTest() throws Exception {
MainActivity activity = Robolectric.setupActivity(MainActivity.class);
Button button = activity.findViewById(R.id.button);
TextView results = activity.findViewById(R.id.textView);
//模擬點擊按鈕,呼叫OnClickListener#onClick
button.performClick();
Assert.assertEquals("Robolectric Rocks!", results.getText().toString());
}
}
運行本段代碼,發現它很本地化測驗一樣,無需運行模擬器或真機,測驗結果如下:

前面的小節介紹了通過儀器化測驗的方式跑到真機上進行測驗SharedPreferences操作,可能吐槽的點都在于耗時太長,現在通過Robolectric改寫為本地測驗來嘗試減少一些耗時,
在實際的專案中,Application可能創建時可能會初始化一些其他的依賴庫,不太方便單元測驗,這里額外創建一個Application類,不需要在清單檔案注冊,直接寫在本地測驗目錄即可,
public class RoboApp extends Application {}
在撰寫測驗類的時候需要通過@Config(application = RoboApp.class)來配置Application,當需要傳入Context的時候呼叫RuntimeEnvironment.application來獲取:
package com.example.hellounittest;
import ...
@RunWith(RobolectricTestRunner.class)
@Config(application = RoboApp.class)
public class RobolectricSharedPreferenceDaoTest {
public static final String TEST_KEY = "instrumentedTest";
public static final String TEST_VALUE = "儀器化測驗";
SharedPreferenceDao spDao;
@Before
public void setUp() {
//這里的Context采用RuntimeEnvironment.application來替代應用的Context
spDao = new SharedPreferenceDao(RuntimeEnvironment.application);
}
@Test
public void sharedPreferenceDaoWriteRead() {
spDao.put(TEST_KEY, TEST_VALUE);
Assert.assertEquals(TEST_VALUE, spDao.get(TEST_KEY));
}
}
運行上面的代碼,會發現它想本地化測驗一樣跑起來了
自動執行界面測驗
通過界面測驗,您可以確保應用滿足其功能要求并達到較高的質量標準,從而更有可能成功地被用戶采用,
界面測驗的一種方法是直接讓測驗人員對目標應用執行一系列用戶操作,并驗證其行為是否正常,不過,這種人工方法會非常耗時、繁瑣且容易出錯,一種更高效的方法是撰寫界面測驗用例,以便以自動化方式執行用戶操作,自動化方法可讓您以可重復的方式快速可靠地運行測驗,
測驗單個應用界面
測驗單個應用內的用戶互動有助于確保用戶在與應用互動時不會遇到意外結果或體驗不佳的情況,如果您需要驗證應用的界面是否正常運行,應養成創建界面測驗的習慣,
Espresso 基本使用
由 AndroidX Test 提供的 Espresso 測驗框架提供了一些 API,用于撰寫界面測驗以模擬單個目標應用內的用戶互動,Espresso 測驗可以在搭載 Android 2.3.3(API 級別 10)及更高版本的設備上運行,使用 Espresso 的主要好處在于,它可以自動同步測驗操作與您正在測驗的應用的界面,Espresso 會檢測主執行緒何時處于空閑狀態,以便可以在適當的時間運行測驗命令,從而提高測驗的可靠性,此外,借助該功能,您不必在測驗代碼中添加任何計時解決方法,如 Thread.sleep(),
Espresso 測驗框架是基于插樁的 API,可與 AndroidJUnitRunner 測驗運行程式一起使用,
配置 Espresso
androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
在測驗設備上關閉影片 - 如果讓系統影片在測驗設備上保持開啟狀態,可能會導致意外結果或導致測驗失敗,通過以下方式關閉影片:在“設定”中打開“開發者選項”,然后關閉以下所有選項:
- 視窗影片縮放
- 過渡影片縮放
- Animator 時長縮放
Example
針對上文的MainActivity,我們再寫一個Espresso框架的界面測驗用例
package com.example.hellounittest;
import ...
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {
@Rule
public ActivityTestRule<MainActivity> activityRule
= new ActivityTestRule<>(MainActivity.class);
@Test
public void clickingButtonTest() throws Exception {
onView(withId(R.id.button)).perform(click());
onView(withId(R.id.textView)).check(matches(withText("Robolectric Rocks!")));
}
}
通過使用 ActivityTestRule,測驗框架會在帶有 @Test 注釋的每個測驗方法運行之前以及帶有 @Before 注釋的所有方法運行之前啟動被測 Activity,該框架將在測驗完成并且帶有 @After 注釋的所有方法都運行后關閉該 Activity,
運行上面的測驗用例,會在模擬器中啟動app,并自動執行用例中的操作,最終得到如下測驗結果,

執行操作
呼叫 onView() 方法并傳入用于指定目標視圖的視圖匹配器,onView() 方法將回傳一個 ViewInteraction 物件,呼叫 ViewInteraction.perform() 或 DataInteraction.perform() 方法,以模擬界面組件上的用戶互動,您必須將一個或多個 ViewAction 物件作為引數傳入,Espresso 將按照給定的順序依次觸發每項操作,并在主執行緒中執行這些操作,
ViewActions 類提供了用于指定常見操作的輔助程式方法的串列,您可以將這些方法用作方便的快捷方式,而不是創建和配置單個 ViewAction 物件,您可以指定以下操作:
- ViewActions.click():點擊視圖,
- ViewActions.typeText():點擊視圖并輸入指定的字串,
- ViewActions.scrollTo():滾動到視圖,目標視圖必須是由 ScrollView 派生的子類,并且其 android:visibility 屬性的值必須為 VISIBLE,對于擴展 AdapterView 的視圖(例如 ListView),onData() 方法將負責為您滾動,
- ViewActions.pressKey():使用指定的鍵碼執行按鍵操作,
- ViewActions.clearText():清除目標視圖中的文本,
如果目標視圖位于 ScrollView 內,請先執行 ViewActions.scrollTo() 操作以在螢屏中顯示該視圖,然后再繼續執行其他操作,如果已顯示該視圖,則 ViewActions.scrollTo() 操作將不起作用,
使用 Espresso Intent 單獨測驗 Activity
Espresso Intent 支持對應用發出的 intent 進行驗證和打樁,使用 Espresso Intent,您可以通過以下方式單獨測驗應用、Activity 或服務:攔截傳出 intent,對結果進行打樁,然后將其發送回被測組件,
- 配置Espresso Intent
- androidTestImplementation 'androidx.test.espresso:espresso-intents:3.3.0'
如需測驗 intent,您需要創建 IntentsTestRule 類(與 ActivityTestRule 類非常相似)的實體,IntentsTestRule 類會在每次測驗前初始化 Espresso Intent,終止托管 Activity,并在每次測驗后釋放 Espresso Intent,
- Example
現在有兩個Activity,FirstActivity可以輸入一個字串并點擊按鈕將字串發送大SecondActivity,SecondActivity接收到字串后,將字串顯示到界面上,
以下是FirstActivity代碼:
package com.example.hellounittest;
import ...
public class FirstActivity extends AppCompatActivity {
public static final String EXTRA_MESSAGE = "com.example.myfirstapp.MESSAGE";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_first);
}
public void sendMessage(View view) {
Intent intent = new Intent(this, SecondActivity.class);
EditText editText = (EditText) findViewById(R.id.edit_message);
String message = editText.getText().toString();
intent.putExtra(EXTRA_MESSAGE, message);
startActivity(intent);
}
}
以下是SecondActivity代碼:
package com.example.hellounittest;
import ...
public class SecondActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
Intent intent = getIntent();
String message = intent.getStringExtra(FirstActivity.EXTRA_MESSAGE);
TextView textView = findViewById(R.id.textView);
textView.setText(message);
}
}
現在新建一個測驗類SimpleIntentTest用于驗證兩個Activity直接傳遞的Intent是否正確,代碼如下:
package com.example.hellounittest;
import ...
@RunWith(AndroidJUnit4.class)
public class SimpleIntentTest {
private static final String MESSAGE = "This is a test";
private static final String PACKAGE_NAME = "com.example.hellounittest";
/* Instantiate an IntentsTestRule object. */
@Rule
public IntentsTestRule<FirstActivity> intentsRule =
new IntentsTestRule<>(FirstActivity.class);
@Test
public void verifyMessageSentToMessageActivity() {
// 在EditText控制元件中輸入一個字串
onView(withId(R.id.edit_message))
.perform(typeText(MESSAGE), closeSoftKeyboard());
// 點擊按鈕,發送一個訊息到第二個Activity
onView(withId(R.id.send_message)).perform(click());
//驗證SecondActivity接收到了一個包含正確報名和訊息的intent
intended(allOf(
hasComponent(hasShortClassName(".SecondActivity")),
toPackage(PACKAGE_NAME),
hasExtra(FirstActivity.EXTRA_MESSAGE, MESSAGE)));
}
}
運行結果如下:

測驗結果通過,耗時954ms
其他
Espresso還可以測驗WebView,可以參考官方示例,
- Espresso 代碼示例包含各種各樣的 Espresso 示例,
測驗多個應用界面
通過涉及多個應用中的用戶互動的界面測驗,您可以驗證當用戶流跨入其他應用或系統界面時,您的應用是否能夠正常運行,
UI Automator 測驗框架來撰寫此類界面測驗,通過 UI Automator API,您可以與設備上的可見元素進行互動,而不管焦點在哪個 Activity 上,您的測驗可以使用方便的描述符(如顯示在相應組件中的文本或其內容描述)來查找界面組件,
I Automator 測驗框架是基于插樁的 API,可與 AndroidJUnitRunner 測驗運行程式一起使用,
配置 UI Automator
androidTestImplementation 'androidx.test.uiautomator:uiautomator:2.2.0'
Example
下面的例子演示在App和Launcher之間切換,在測驗App功能之前會先回到Launcher,然后再從Launcher啟動App,然后測驗App首頁的功能,測驗代碼如下:
package com.example.hellounittest;
import ...
@RunWith(AndroidJUnit4.class)
public class ChangeTextBehaviorTest {
private static final String BASIC_SAMPLE_PACKAGE = "com.example.hellounittest";
private static final int LAUNCH_TIMEOUT = 5000;
private static final String STRING_TO_BE_TYPED = "Robolectric Rocks!";
private UiDevice mDevice;
@Before
public void startMainActivityFromHomeScreen() {
// 初始化UiDevice物件
mDevice = UiDevice.getInstance(getInstrumentation());
// 模擬按下home鍵回到桌面
mDevice.pressHome();
// 等待回到桌面
final String launcherPackage = getLauncherPackageName();
assertThat(launcherPackage, notNullValue());
mDevice.wait(Until.hasObject(By.pkg(launcherPackage).depth(0)), LAUNCH_TIMEOUT);
// 啟動自己的測驗app
Context context = getApplicationContext();
final Intent intent = context.getPackageManager()
.getLaunchIntentForPackage(BASIC_SAMPLE_PACKAGE);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK); // Clear out any previous instances
context.startActivity(intent);
// 等待自己的測驗app啟動
mDevice.wait(Until.hasObject(By.pkg(BASIC_SAMPLE_PACKAGE).depth(0)), LAUNCH_TIMEOUT);
}
@Test
public void testChangeText_sameActivity() {
// Type text and then press the button.
mDevice.findObject(By.res(BASIC_SAMPLE_PACKAGE, "button"))
.click();
// Verify the test is displayed in the Ui
UiObject2 changedText = mDevice
.wait(Until.findObject(By.res(BASIC_SAMPLE_PACKAGE, "textView")), 500);
assertThat(changedText.getText(), is(equalTo(STRING_TO_BE_TYPED)));
}
private String getLauncherPackageName() {
// Create launcher Intent
final Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_HOME);
// Use PackageManager to get the launcher package name
PackageManager pm = getApplicationContext().getPackageManager();
ResolveInfo resolveInfo = pm.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY);
return resolveInfo.activityInfo.packageName;
}
}
運行上面的代碼,會看到模擬器先回到桌面,然后再啟動App,然會點擊App首頁的按鈕,最后驗證字串是否改變,最后測驗結果如下:

UiDevice 物件是您訪問和操縱設備狀態的主要方式,在測驗中,您可以呼叫 UiDevice 方法檢查各種屬性的狀態,如當前螢屏方向或顯示屏尺寸,您的測驗可以使用 UiDevice 物件執行設備級操作,如強制設備進行特定旋轉、按方向鍵硬體按鈕,以及按主螢屏和選單按鈕,
UI Automator 測驗類的撰寫方式應與 JUnit 4 測驗類相同,在測驗類定義的開頭添加 @RunWith(AndroidJUnit4.class) 注釋,
在 UI Automator 測驗類中實作以下編程模型:
- 通過呼叫 getInstance() 方法并將 Instrumentation 物件作為引數傳遞給該方法,獲取 UiDevice 物件以訪問要測驗的設備,
- 通過呼叫 findObject() 方法,獲取 UiObject 物件以訪問設備上顯示的界面組件(例如,前臺的當前視圖),
- 通過呼叫 UiObject 方法,模擬需要在該界面組件上執行的特定用戶互動;例如,呼叫 performMultiPointerGesture() 以模擬多點觸控手勢,以及呼叫 setText() 以修改文本欄位,您可以根據需要反復呼叫第 2 步和第 3 步中的 API,以測驗涉及多個界面組件或用戶操作序列的更復雜的用戶互動,
- 執行這些用戶互動后,檢查界面是否反映了預期的狀態或行為,
- 啟動更多操作請參考官方檔案
官方資料
針對Android的測驗還有很多,比如針對Service的測驗,比如針對ContentProvider的測驗等,這些測驗同上面的針對Activity的測驗差異不大,詳細的測驗資料可參考官方資料:
https://developer.android.com/training/testing/unit-testing/
轉載請註明出處,本文鏈接:https://www.uj5u.com/yidong/238088.html
標籤:其他
