本文由 玉剛說寫作平臺 提供寫作贊助
原作者：卻把清梅嗅
原文地址：https://mp.weixin.qq.com/s/ODbqUHjQUTA79UyI5Fw5Mw
版權(quán)聲明：本文版權(quán)歸微信公眾號 玉剛說 所有，未經(jīng)許可椰憋，不得以任何形式轉(zhuǎn)載厅克！
困境
你在南方的艷陽里，手指紛飛橙依；我在北方的寒夜里证舟，喝杯咖啡。
接下來我將說到這種情況并非個例——作為一個Android開發(fā)者窗骑，當(dāng)我實現(xiàn)了一個界面的一些功能女责，或者對界面上某些功能進行了修改，我該如何去查收我想要的結(jié)果呢创译？
最簡單的方式就是直接編譯運行App抵知，通過自己的操作對界面進行交互，從個人的視覺效果上進行功能的檢查，比如我實現(xiàn)了一個RecyclerView刷喜，我就打開界面残制，看看這個列表是否正確顯示在了界面上。
不久之后掖疮，我覺得某些地方代碼不是很好初茶，于是我改了一些代碼，我怕會出現(xiàn)問題浊闪，于是為了保證項目能夠不出問題（至少是避免低級的錯誤）规揪，我選擇再次編譯運行字支，驗收結(jié)果。
再深入一點，如果每個版本發(fā)布前都需要這么多次測試富俄，或者每當(dāng)我們簡單修改了一下代碼暴备，就需要更多次重復(fù)進行以上步驟，并檢測結(jié)果障癌，來來往往，反反復(fù)復(fù)，實在令人乏味惦辛。
也許， UI自動化測試是一勞永逸解決這個問題的方案之一嗽冒。
UI自動化測試簡介
- 充滿熱情添坊，一腔熱血贬蛙，說學(xué)就學(xué)阳准，我行我上。
相信我讼稚，不要這樣乱灵，這和學(xué)習(xí)庫或者框架不一樣痛倚，UI自動化測試是一個專業(yè)技能蝉稳。不信的話操漠，請參考一下各大機構(gòu)對于測試工程師的培訓(xùn)周期，系統(tǒng)性走一遍全日制要幾個月，閑暇時間學(xué)習(xí)吻贿？學(xué)不完的舅列，而且帐要，沒必要榨惠。
有哪些測試工具？
以Android官方文檔的概述伸蚯，AndroidStudio提供了幾種UI測試工具供開發(fā)者使用剂邮。
事實上UI的自動化測試工具很多挥萌，但對于Android開發(fā)者來講引瀑，掌握其中的1至2項榨馁，就足以在UI測試領(lǐng)域立足翼虫，本文僅簡單介紹基礎(chǔ)的幾款工具以拋磚引玉珍剑。
1.Monkey
Monkey是Android SDK自帶的測試工具招拙，在測試過程中會向系統(tǒng)發(fā)送偽隨機的用戶事件流，如按鍵輸入菌羽、觸摸屏輸入、手勢輸入等)层扶，實現(xiàn)對正在開發(fā)的應(yīng)用程序進行壓力測試戳表，也有日志輸出。實際上該工具只能做程序做一些壓力測試，由于測試事件和數(shù)據(jù)都是隨機的佩伤，不能自定義须揣，所以有很大的局限性。
Monkey是Android SDK自帶的測試工具，在測試過程中會向系統(tǒng)發(fā)送偽隨機的用戶事件流，如按鍵輸入讯赏、觸摸屏輸入漱挎、手勢輸入等)磕谅，實現(xiàn)對正在開發(fā)的應(yīng)用程序進行壓力測試膊夹，也有日志輸出。實際上該工具只能做程序做一些壓力測試进统，由于測試事件和數(shù)據(jù)都是隨機的螟碎，不能自定義，所以有很大的局限性俭缓。
2.Instrumentation
Instrumentation是早期Google提供的Android自動化測試工具類华坦，雖然在那時候JUnit也可以對Android進行測試洗搂，但是Instrumentation允許你對應(yīng)用程序做更為復(fù)雜的測試耘拇，甚至是框架層面的惫叛。通過Instrumentation你可以模擬按鍵按下妻熊、抬起扔役、屏幕點擊亿胸、滾動等事件预皇。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現(xiàn)這些功能，你可以把Instrumentation看成一個類似Activity或者Service并且不帶界面的組件吟温，在程序運行期間監(jiān)控你的主程序鲁豪。缺點是對測試人員來說編寫代碼能力要求較高挥等，需要對Android相關(guān)知識有一定了解迁客，還需要配置AndroidManifest.xml文件掷漱，不能跨多個App。
3.UiAutomator
UiAutomator也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實現(xiàn)細(xì)節(jié)（可以用UiAutomatorviewer抓去App頁面上的控件屬性而不看源碼）沪袭∠丽基于Java，測試代碼結(jié)構(gòu)簡單、編寫容易、學(xué)習(xí)成本静盅，一次編譯明垢，所有設(shè)備或模擬器都能運行測試，能跨App（比如：很多App有選擇相冊、打開相機拍照致稀，這就是跨App測試）。缺點是只支持SDK 16（Android 4.1）及以上，不支持Hybird App蔑歌、WebApp雳刺。
4.Espresso
Espresso是Google的開源自動化測試框架。相對于Robotium和UIAutomator枪汪，它的特點是規(guī)模更小趁舀、更簡潔越庇，API更加精確涩惑，編寫測試代碼簡單，容易快速上手。因為是基于Instrumentation的，所以不能跨App亭螟。
以上這些工具的概述道媚，節(jié)選引用自知乎：Android 手機自動化測試工具有哪幾種？
如何入門？
UI的自動化測試的是一個復(fù)雜的系統(tǒng)沙兰，所謂望山跑死馬熟丸，作為Android開發(fā)者怀大，我們想要通過閑暇的時間捡多，期望短期能夠精通UI自動化測試是不現(xiàn)實的蒜焊，但是每次都運行app手動測試又顯得很蠢榜掌，最好的方式，是通過了解并學(xué)習(xí)一個經(jīng)典的UI測試工具，在了解到UI自動化測試的好處之后，再選擇繼續(xù)深入還是功成身退嚷兔。
有心的同學(xué)已經(jīng)注意到了，上文中最后介紹的那個Espresso怎么這么眼熟呢？確實如此，在AndroidStudio2.2版本之后，在新建的項目中，AndroidStudio會默認(rèn)添加Espresso的依賴。
這樣看來，Espresso顯然是一個不錯的選擇催享。正如Google所希望的，當(dāng)Android的開發(fā)者利用Espresso寫完測試用例后，能一邊看著測試用例自動執(zhí)行，一邊享受一杯香醇的Espresso(意式咖啡)。
Espresso學(xué)習(xí)指南
沒事走兩步
Google官方希望我們通過Espresso減少重復(fù)的勞動，那么這所謂的UI自動化測試效果如何呢传泊，正所謂手下見真章薪鹦，我們來看一下Google的todo App的測試代碼運行時的效果：
Espresso的原理是，通過測試代碼模擬用戶對UI元素的操作，之后再校驗（verify）操作后的結(jié)果筛圆，和我們人為操作不同提岔，Espresso能夠在短時間內(nèi)測試所有的case，正如你所見的一樣坊秸。
我們不禁這樣想阶牍，如果一個界面涉及到很多的操作，沒有Espresso測試代碼之前星瘾，每次修改走孽，工作的責(zé)任感需要讓我自己先跑一遍所有功能，然后才敢打包扔給QA琳状，但是如果我寫好了自動化測試代碼磕瓷，是不是意味著每次改完代碼，只需跑一遍測試代碼就代替了之前的手工操作呢念逞？
如您所見困食，本次測試了一個界面19個不同的操作，整個自動化過程共花費了4m34s翎承，但在這個過程中我可以沖一杯咖啡硕盹，或者看看技術(shù)博客，甚至是發(fā)呆——我愜意地得到了期冀的結(jié)果叨咖。
如果我負(fù)責(zé)的功能模塊所有界面瘩例，都覆蓋了這樣的測試代碼，多好啊......——如果屏幕面前的您甸各，有學(xué)習(xí)借助自動化測試工具偷懶的想法垛贤，請堅持閱讀下去，以一個開發(fā)人員而非專業(yè)測試人員的視角趣倾，分享學(xué)習(xí)自動化測試的經(jīng)驗聘惦，這也正是本文的目的。
主旨
本文的目標(biāo)是誊酌，以自己的學(xué)習(xí)經(jīng)歷為基礎(chǔ)部凑，為想要學(xué)習(xí)Espresso（或者有這個想法）的同學(xué)，提供一個系統(tǒng)性的規(guī)劃和建議碧浊。
這意味著涂邀，本文不會去詳細(xì)闡述每個API的使用，于我而言箱锐，這些應(yīng)該交給官方文檔去闡釋比勉，當(dāng)然，對于API而言驹止，我也不認(rèn)為能夠講述的比官方文檔更優(yōu)秀浩聋。
我會通過一些簡單的測試代碼闡述UI自動化測試所需要的一些基礎(chǔ)或思想，但是代碼本身不應(yīng)該是本文的重點臊恋，我更希望衣洁，當(dāng)您讀完本文，您能有啊抖仅，原來Espresso的UI測試應(yīng)該這么學(xué)之感——而不是哦坊夫，原來這個API是這么用的砖第。
如果將本文的定義類比于該知識體系的目錄或者導(dǎo)航，我覺得再恰當(dāng)不過环凿。
如何學(xué)習(xí)Espresso
我的建議是按照以下步驟進行學(xué)習(xí)：
- 1.Fork Google官方的Demo代碼梧兼，運行并感受測試代碼的威力
Google官方的todo案例地址：
https://github.com/googlesamples/android-architecture
我們拉下來代碼后，選一個您比較感興趣的分支智听，比如比較簡單一點的todo-mvp分支羽杰，這個分支中代碼的實現(xiàn)僅僅使用了MVP的架構(gòu)，學(xué)習(xí)起來并不復(fù)雜到推。
我們來看一下項目的目錄結(jié)構(gòu)：
其中androidTest和androidTestMock都是UI測試的代碼考赛，我們先右鍵點擊androidTest文件夾，run該文件夾下的所有UI測試case环肘。
選中設(shè)備后欲虚，AndroidStudio就會編譯并自動打包（注意實際上此處的測試打包和實際生產(chǎn)的打包并不一樣），然后自動在設(shè)備上運行所有的測試case——就和上文中的效果一樣悔雹。
看到這里复哆，我們不僅感嘆測試代碼的強大，不要沉迷于此腌零，我們繼續(xù)第二步：
- 2.閱讀Espresso的官方文檔
如果點進去看測試代碼的話梯找，我們會比較懵逼，因為我們對于Espresso的使用一無所知益涧，那么接下來我們要去做的锈锤，就是閱讀Espresso的官方文檔了：
https://developer.android.com/training/testing/espresso/basics
https://lovexiaov.gitbooks.io/official-espresso-doc/content/
中文翻譯的gitbook的確不好找，在此不僅感嘆UI自動化測試的小眾性闲询，特別感謝譯者lovexiaov久免，沒有你的分享精神，我就只能考慮自己去硬啃英文文檔了扭弧。
實話說阎姥，中文的文檔部分翻譯不夠準(zhǔn)確，建議大家鸽捻，有能力還是看英文原版呼巴，我更建議大家中英文對照學(xué)習(xí)。
這一步御蒲，我們不需要深入學(xué)習(xí)并使用文檔中列舉的所有API衣赶，只需要參照文檔看得懂todoApp中測試代碼的用意就行了。
- 3.付諸實踐
當(dāng)我們參照API文檔厚满，并且能夠基本看得懂demo代碼中府瞄，大部分測試case想要干什么，我們接下來就可以嘗試付諸實踐了碘箍。
實踐
接下來我將會用簡單的代碼闡述Espresso的簡單使用摘能。
1.Hello Espresso!
來一個最簡單的demo续崖，當(dāng)我們點擊一個Button敲街，讓界面某個TextView顯示HelloEspresso的文字內(nèi)容团搞。
我們忽略xml布局的實現(xiàn)，簡單看一下Activity中的部分Java代碼：
public void onViewClicked(View view) {
switch (view.getId()) {
case R.id.button:
// 點擊button后多艇，textview顯示hello espresso!
textView.setVisibility(View.VISIBLE);
textView.setText("hello espresso!");
break;
}
}
非常簡單逻恐，測試代碼自然也淺顯易懂：
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {
@Rule
public ActivityTestRule<MainActivity> rule =
new ActivityTestRule<>(MainActivity.class);
@Test
public void clickTest() {
//檢驗：一開始，textView不顯示
onView(withId(R.id.textView))
.check(matches(not(isDisplayed())));
//檢驗：button的文字內(nèi)容
onView(withId(R.id.button))
.check(matches(withText("修改內(nèi)容")))
.perform(click()); //操作：點擊按鈕
//檢驗：textView內(nèi)容是否修改峻黍，并且變?yōu)榭梢? onView(withId(R.id.textView))
.check(matches(withText("hello espresso!")))
.check(matches(isDisplayed()));
}
}
代碼非常簡單复隆，邏輯也很清晰，我們測試的思路是姆涩，找到我們要操作的界面元素挽拂，然后操作該界面元素，然后校驗UI的變化骨饿。
在這個測試中亏栈，當(dāng)我們點擊了button后，會校驗：界面上TextView變?yōu)榭梢姾曜福瑫r附有“hello espresso!”的內(nèi)容——如果測試失敗了绒北，說明我們預(yù)期的操作并未得到預(yù)期的結(jié)果，我們就需要去檢查代碼了察署。
2.模擬用戶的登陸操作
接下來我們跳轉(zhuǎn)另外一個場景闷游，稍微復(fù)雜一點，界面上有一個EditText贴汪，負(fù)責(zé)用戶輸入賬號脐往，還有一個Button，負(fù)責(zé)登錄扳埂，還有一個TextView业簿，當(dāng)用戶點擊Button后，TextView會顯示登錄成功并且清空輸入框：
public void onViewClicked(View view) {
switch (view.getId()) {
case R.id.button2:
// 登陸成功并且清空輸入框
textView.setVisibility(View.VISIBLE);
textView.setText("登錄成功");
editText.setText("");
break;
}
}
我們可以這樣補充測試Case：
@Test
public void loginTest() throws Exception {
//先清除editText的內(nèi)容聂喇，然后輸入辖源，然后關(guān)閉軟鍵盤，最后校驗內(nèi)容
//這里如果要輸入中文希太，使用replaceText()方法代替typeText()
onView(withId(R.id.editText))
.perform(
clearText(),
replaceText("username"),
closeSoftKeyboard()
)
.check(matches(withText("username")));
// 操作：點擊Button
onView(withId(R.id.button2))
.perform(click());
//校驗：textView的內(nèi)容和可見
onView(withId(R.id.textView))
.check(matches(withText("登錄成功")))
.check(matches(isDisplayed()));
//校驗：editText的文字內(nèi)容（被清空）和hint
onView(withId(R.id.editText))
.check(matches(withText("")))
.check(matches(withHint("請輸入賬戶名")));
}
大功告成——和基本案例基本差不多克饶，都是通過簡單的對View的操作+校驗完成了UI的測試代碼編寫。
看起來我們已經(jīng)熟悉了Espresso的使用套路誊辉，我已經(jīng)有信心在真實的項目中應(yīng)用它了矾湃。
3.熟練使用Espresso進行UI自動化測....等等！
正所謂行百里路半九十堕澄，當(dāng)我們將看起來并不復(fù)雜的Espresso應(yīng)用在真實的項目中時邀跃，我們馬上就會遇到一個很嚴(yán)重的問題霉咨，那就是：
并非所有的UI操作都是同步響應(yīng)的！
Espresso進行一個簡單的同步功能測試并不難拍屑，比如我們點擊了一個Button,點擊后改變對應(yīng)某個TextView的內(nèi)容途戒，這很簡單。但實際正常開發(fā)中僵驰，這種簡單的邏輯測試是很少見的喷斋，相反，我們需要測試的是各種各樣的異步測試蒜茴，比如：
情景一：點擊進入Activity星爪，網(wǎng)絡(luò)請求數(shù)據(jù)加載，成功后數(shù)據(jù)展示在界面上粉私。
情景二：點擊進入Activity顽腾，獲得緩存，網(wǎng)絡(luò)請求數(shù)據(jù)加載诺核，成功后數(shù)據(jù)展示在界面上抄肖，處理緩存。
情景N : ......
假設(shè)這樣一個簡單的網(wǎng)絡(luò)請求測試：
@Test
public void testHttp() {
// 我們請求網(wǎng)絡(luò)數(shù)據(jù)猪瞬，成功后讓TextView顯示"網(wǎng)絡(luò)請求成功"
// 同時ImageView從不可見變?yōu)榭梢?
//如果我們直接檢查是不是請求到了數(shù)據(jù)
onView(withId(R.id.textView)).check(matches(withText("網(wǎng)絡(luò)請求成功憎瘸！")));
onView(withText(R.id.imageView)).check(matches(isDisplayed()));
}
如果我們直接測試，那么很大概率會報錯陈瘦，因為在我們要測試數(shù)據(jù)是否展示在UI上時幌甘，網(wǎng)絡(luò)數(shù)據(jù)很有可能還沒有獲取到。
這很難處理痊项，因為我們不知道數(shù)據(jù)到底什么時候才能獲取到锅风，有同學(xué)抖了個機靈，說我們可以這樣：
@Test
public void testHttp() {
// 我們一進來就先讓他等待5秒鞍泉，等數(shù)據(jù)加載完畢再檢查UI
Thread.sleep(5000)皱埠；
// 5秒結(jié)束，我們檢查是不是請求到了數(shù)據(jù)
onView(withId(R.id.textView)).check(matches(withText("網(wǎng)絡(luò)請求成功咖驮！")));
onView(withText(R.id.imageView)).check(matches(isDisplayed()));
}
這樣可以實現(xiàn)嗎边器，這個大概率真的可以，但是這種測試顯然問題很多托修，因為網(wǎng)絡(luò)情況是在不斷變化的忘巧，也許0.5s就能獲取網(wǎng)絡(luò)數(shù)據(jù)，也有可能數(shù)十秒后才能獲取睦刃，這樣前者導(dǎo)致我們浪費了4.5s的時間砚嘴，后者在網(wǎng)絡(luò)狀態(tài)屬于正常的時候測試結(jié)果失敗，這都是我們不愿看到的結(jié)果。
我們更希望在獲取到網(wǎng)絡(luò)數(shù)據(jù)之后际长，立即進行下一步的測試耸采，因此我們需要對網(wǎng)絡(luò)數(shù)據(jù)的獲取情況進行監(jiān)聽。
但是問題來了工育，如何在UI測試代碼中虾宇，對真實的網(wǎng)絡(luò)狀態(tài)進行監(jiān)聽呢？
這個問題難倒了我翅娶，好在Google的工程師們已經(jīng)在todo的demo中提供了一種解決的方式文留，我們來看一看官方的方案。
4.異步操作的測試思路
Google官方提供了IdlingResource以供開發(fā)者進行UI的異步測試竭沫，對于IdlingResource的解釋說明，我們可以參照官方文檔：
https://developer.android.com/training/testing/espresso/idling-resource
或者中文文檔對于IdlingResource的解釋：
https://lovexiaov.gitbooks.io/official-espresso-doc/content/chapter6.html
我不會用大段代碼闡述如何使用骑篙，它的基本原理是：在生產(chǎn)代碼中蜕提，定義一個Flag（標(biāo)記），當(dāng)開始異步請求前靶端，修改Flag的狀態(tài)谎势，當(dāng)網(wǎng)絡(luò)請求結(jié)束后，將Flag的狀態(tài)重置杨名，這時候Flag狀態(tài)修改的事件會被發(fā)送通知給注冊的對象（比如測試代碼）：
@Before
public void setUp() throws Exception {
idlingresource = activityRule.getActivity().getIdlingresource();
}
@Test
public void onLoadingFinished() throws Exception {
// 不再需要這樣的代碼
// Thread.sleep(5000);
// 注冊異步監(jiān)聽脏榆，此時測試會被掛起
// 當(dāng)網(wǎng)絡(luò)請求結(jié)束后，生產(chǎn)代碼中Flag狀態(tài)的改變台谍，會繼續(xù)執(zhí)行測試代碼
Espresso.registerIdlingResources(idlingresource);
// 繼續(xù)執(zhí)行代碼
onView(withId(R.id.text))
.check(matches(withText("success!")));
}
@After
public void release() throws Exception {
// 當(dāng)然须喂，我們需要在測試結(jié)束后取消注冊，釋放資源
Espresso.unregisterIdlingResources(idlingresource);
}
這種行為的好處不言而喻趁蕊，它能夠在異步結(jié)束之后馬上執(zhí)行接下來的測試代碼坞生，從效果上來說，相比Thread.sleep(5000);不知好了多少掷伙。
它的缺點也很明顯是己，那就是測試代碼實際需要依賴對生產(chǎn)代碼進行配置（本文中并未展示，請參考todoDemo或者這篇文章）任柜。
難道就沒有更好的解決方案嗎卒废？當(dāng)然有，Google對此的建議是宙地，重構(gòu)項目代碼（比如增加product flavors摔认，或者通過依賴注入等等），使其變得可測試性——到這一步绸栅，請慎重考慮级野，因為這已經(jīng)涉及到項目的架構(gòu)以及項目管理的層級上了。
5.更多
實際上，Espresso在應(yīng)用在實際項目中蓖柔，需要我們?nèi)ッ鎸Φ膯栴}并不少辰企，絕大多數(shù)情況下，這些問題都能夠通過搜索引擎然后親自實踐去解決—— 你絕不是一個人在戰(zhàn)斗况鸣。
小結(jié)——堅持還是放棄牢贸？
很多同學(xué)都了解單元測試和UI自動化測試的重要性，但是這些工具需要不菲的時間成本镐捧，那么它們真的還有必要去學(xué)習(xí)嗎潜索？
有位同學(xué)舉手了，他同樣表示——有時雖然修改一個小功能懂酱，需要開發(fā)者多次手動測試很麻煩竹习，但是也并非不可接受，至少上班時列牺，在項目編譯運行期間整陌，我可以切換網(wǎng)頁，看看新聞摸摸魚瞎领。
當(dāng)然還有這樣的情況泌辫，作為一個開發(fā)人員，即使我學(xué)會了自動化測試九默，我也不一定有機會去應(yīng)用它震放，直接嘗試應(yīng)用在一個已經(jīng)完善的成熟項目中，是不現(xiàn)實的驼修；這樣的話殿遂，會不會出現(xiàn)，學(xué)會了但根本用不到的窘境邪锌？
每個人都不能保證將來還是否還會遇到曾經(jīng)的問題勉躺，如果遇到了，我該怎么做觅丰，是選擇繼續(xù)躲避饵溅，還是一勞永逸；而且妇萄，即使學(xué)會了蜕企，如何保證這能成為我核心競爭力的一部分，而不是學(xué)會了卻用不到冠句，最終被慢慢忘記轻掩？
的確，我們有時的確沒有必要為工作做出額外的付出（思考和實踐）懦底，萬一搞砸了唇牧，反而不如不做。但是我要闡述的一點是：不做并不意味著問題被解決了——你只是暫時避開了它，而下一次遇到它的時候丐重，你仍需去面對這個困境腔召；并且，如果將測試任務(wù)交給了代碼扮惦，摸魚的時候豈不更加輕松臀蛛？正所謂，授人以漁崖蜜，勞神費力浊仆。而——
我的思路
言歸正傳，對于如何實踐自動化測試豫领，我的方式是對個人的一些工具代碼進行UI自動化測試的覆蓋抡柿，在進一步完善自己的工具同時，深入了解Espresso氏堤。
筆者對于Espresso的經(jīng)驗所得來自于自己的Github的這個工具沙绝，它是Android的一個響應(yīng)式圖片選擇器，因此每次發(fā)布新版本筆者都需要自己測試UI鼠锈，而UI自動化測試無疑可以減少這些重復(fù)的操作。 ——這個庫UI測試的更詳細(xì)過程并非本文的重點星著，我在另一篇文章中去闡述了它:
全副武裝购笆！AndroidUI自動化測試在RxImagePicker中的實踐歷程
一千個觀眾眼中有一千個哈姆雷特，只要感興趣虚循，總能找到適合自己的方式同欠，本文所講述的Espresso僅僅是UI自動化測試這門專業(yè)技術(shù)的一部分，但我認(rèn)為它很契合Android開發(fā)者横缔，并借助它為自己的UI界面進行白盒測試（也有朋友稱Espresso為灰盒測試）铺遂，正如官方文檔所描述的（下為譯文）：
Espresso 的使用群體為堅信自動化測試是開發(fā)周期中必不可少的一部分的開發(fā)者。雖然它可被用來做黑盒測試茎刚，但 Espresso 會在對被測代碼庫熟悉的人手中火力全開襟锐。
在我們感嘆AndroidStudio默認(rèn)提供的依賴庫中，JUnit4可以讓我們通過單元測試保證最小模塊代碼的可靠性膛锭，ConstraintLayout讓我們減少大量布局嵌套的同時慢慢拋棄了RelativeLayout的同時粮坞，請也不要忽視Espresso，真正了解了它并付諸實踐初狰，便會對它強大的UI自動化測試功能愛不釋手莫杈。
