Hello深滚，親愛的讀者朋友們（希望你們是 Android 開發(fā)者，或者正在成為 Androider 的路上…）华嘹！
質(zhì)量從用戶反饋很清涼然后我們就只能看 CPU 原來的想法是但是事實上不是這些但是我們可以把數(shù)據(jù)收集上來反浓，從長遠(yuǎn)角度來說任内，我們呢很簡單，怎樣擺脫這種要辭職的想法牌里，那我能去哪颊咬，要干啥，任何團(tuán)隊都有一定的問題牡辽，如果他走喳篇，我覺得我還可以接受缺一個告警什么叫我們的團(tuán)隊當(dāng)時是
Android 開發(fā)現(xiàn)在陷入了困境（快陷入七年了…）。大部分程序都沒有測試功能（單元測試态辛、集成測試和功能測試）麸澜；也都忽略了編譯和 lint 警告；并且代碼都看起來像意大利面（但愿是有反應(yīng)的意大利面…）等等等等奏黑。
壞消息：在 Android 開發(fā)文化的源頭痰憎， Google 就直接參與了這一切。
質(zhì)量為王
是的攀涵，Google 以#執(zhí)行為王著稱铣耘，但#質(zhì)量為王其實是更應(yīng)該先做到的重要事項。
對質(zhì)量水平不高的代碼進(jìn)行優(yōu)化以故，會造成不成熟的優(yōu)化蜗细，而不成熟的優(yōu)化也被成為萬惡之源（雖然并非絕對，但大多情況下是這樣的）怒详。
好消息：像 Square炉媒、SoundCloud、Twitter 這樣的企業(yè)和一些開發(fā)者正通過發(fā)表演講昆烁、撰寫博客吊骤，讓 Android 開發(fā)變得更好，感謝他們静尼！此外白粉， Google 似乎終于對提高 Android 應(yīng)用程序的質(zhì)量產(chǎn)生興趣了！近期鼠渺， Google 參加了 Android 開發(fā)峰會（AndroidDevSummit）和一些其他會議鸭巴，我們看到了一些關(guān)于測試的內(nèi)容，請繼續(xù)保持拦盹！
現(xiàn)在是時候來提高 Android 開發(fā)的質(zhì)量了鹃祖。
Android 開發(fā)文化暨說明文檔。
0. Fail fast 機(jī)制：盡快宕機(jī)普舆，盡早放棄恬口。
為什么這么說呢校读？— 因為你要在產(chǎn)品到達(dá)用戶之前找到問題，那么越快祖能、越早的宕機(jī)地熄，對你就越有利，其實這也是你該做的芯杀。
本文每一項都會遵循這個基本原則端考。
1. Pull 請求、代碼審核和持續(xù)集成
項目開發(fā)應(yīng)該在版本控制系統(tǒng)內(nèi)完成揭厚。開發(fā)過程應(yīng)該通過Pull請求（以下全文簡稱 PRs）却特，并經(jīng)過代碼審核，否則任何代碼都不能直接推送到主開發(fā)分支上筛圆。每次 PR 會應(yīng)該觸發(fā)持續(xù)集成（以下全文簡稱 CI）系統(tǒng)裂明，并構(gòu)建項目。構(gòu)建應(yīng)該是可重復(fù)的太援，每一個隊伍里的成員都應(yīng)該可以輕松地構(gòu)建項目闽晦。
Fail early：如果 PR 的構(gòu)建在 CI 系統(tǒng)中失敗了，在修復(fù)完成之前提岔，PR 不要進(jìn)行合并仙蛉。
2. 代碼質(zhì)量
你的代碼應(yīng)該是堅實的 或者結(jié)實的。如何做到這一點碱蒙，完全取決于你自己荠瘪。代碼質(zhì)量并不只和 MVP/MVVM/MVC 有關(guān)，同時也和 App 中每個組件的每一行代碼有關(guān)赛惩。筆者更傾向使用純函數(shù)和不可變對象哀墓。
Fail early：不要成為項目中唯一編寫可維護(hù)的代碼的開發(fā)者，確保其他成員也可以寫高質(zhì)量的代碼（和他們聊天喷兼，一起討論本文即可激勵他們＠捍隆），從而防止審核時出現(xiàn)糟糕的代碼季惯。
3. 靜態(tài)代碼/資源分析
靜態(tài)代碼分析讓你在進(jìn)入生產(chǎn)環(huán)境之前找到代碼中的問題吠各。同時，也對代碼審核大有裨益星瘾。比如使用 Android Lint走孽、FindBugs、PMD琳状、SonarQube 和 FB Infer 等工具。
Fail early：在 CI 中運行靜態(tài)分析盒齿，安裝配置后念逞，如果項目中出現(xiàn)警告（不僅僅是錯誤信息）困食，盡早放棄項目。
4. 單元測試
是的翎承！是測試沒錯硕盹！單元測試通常會檢查某個函數(shù)/對象是否正確地完成它的工作。項目里的測試越多叨咖，代碼覆蓋率越高瘩例， App 在發(fā)布后的性能，會更好更穩(wěn)定甸各。事實上垛贤，單元測試可以發(fā)現(xiàn)大多數(shù)愚蠢的 bug。當(dāng)然趣倾，如果你的 App 會進(jìn)行數(shù)據(jù)處理的話聘惦，單元測試還將幫助你保證代碼工作正常。
Android 項目單元測試的簡易指南
筆者傾向于在 JVM 上運行單元測試儒恋，因為它比在設(shè)備/模擬器上運行快得多善绎。
Android 的 Gradle 插件可以運行在JVM上的單元測試。只要把測試加至
test/ java_or_other_lang即可诫尽。你可以從 IDE 運行測試（右鍵點擊測試->運行）或者從
./gradlew test終端禀酱。你很快就會發(fā)現(xiàn)，如果在 JVM 運行單元測試牧嫉，Android SDK 的類會被清除比勉，觸發(fā)他們時會拋出異常。這固然可悲驹止，但是是可修復(fù)的浩聋。如果需要 Android SDK 類的話，可以在 Robolectric 測試運行器下運行臊恋，Robolectric 提供了大部分實現(xiàn) Android SDK 類的方法衣洁。JUnit 提供了很棒的測試工具和相當(dāng)不錯的 Rules 概念，但是 JUnit 的斷言很不好用抖仅。 AssertJ 和 Truth 等工具對斷言的支持很好坊夫，并且可以在 JUnit （或 TestNG/Spock 等）下運行。如果你需要檢查行為和復(fù)制某些對象撤卢，你可以使用 Mockito 之類的復(fù)制庫环凿。
TDD 與否，取決于你放吩，但絕對值得一試智听！
Fail early: 在 CI 中運行單元測試，如果有一些測試失敗了，則盡早放棄到推。
5. 代碼覆蓋率
一旦開始編寫單元測試考赛，你便需要知道代碼覆蓋率是否足夠好。
像 Jacoco 這樣的工具可以幫助你檢查測試程序所走的代碼路徑莉测。如果你測試的代碼表現(xiàn)依賴于條件語句颜骤，代碼覆蓋率就尤為重要，因為你需要確保代碼執(zhí)行中的所有可能都得到檢查捣卤。
你可以通過apply plugin: ‘jacoco’語句啟用 Jacoco忍抽。你可以通過jacocoReport Gradle 任務(wù)配置哪些類/包應(yīng)該被檢查。
如果覆蓋率不夠高董朝，配置代碼覆蓋工具使之放棄構(gòu)建項目鸠项。如果你剛剛開始在一個已存在的項目中使用單元測試，除了非測試類益涧，一旦測試代碼可以覆蓋這些類锈锤，就將它們從排除列表中刪除。這個規(guī)則可以保證新代碼的覆蓋率闲询。根據(jù)覆蓋報告久免，你可以使用 jacoco-coverage 插件放棄構(gòu)建。
Fail early：確保在 CI 環(huán)境中檢查代碼覆蓋率扭弧，如果代碼覆蓋率不夠高阎姥，盡早放棄構(gòu)建。
6. 功能（UI）測試
沒錯鸽捻！更多的測試呼巴。功能測試會從用戶的角度檢查 APP 的功能。功能測試啟動應(yīng)用程序后御蒲，會驗證某些功能衣赶，比如在 UI 界面中加載出的數(shù)據(jù)是否正確顯示。QA 團(tuán)隊進(jìn)行的大部分工作可以通過功能測試達(dá)到自動化厚满，但這并不意味著你不需要 QA 團(tuán)隊府瞄。
運行功能測試有兩種基本的方法，在 Android Instrumentation 或 UIAutomator 里運行碘箍。最主要的區(qū)別是遵馆，在 Android Instrumentation 里運行功能測試時只能與應(yīng)用程序交互，并可以接觸到程序代碼丰榴。在 UIAutomator 里進(jìn)行的測試會運行在系統(tǒng)進(jìn)程中货邓，并通過Accessibility API（相比于 Android Intrumentation，此方式的功能十分有限）和應(yīng)用程序進(jìn)行交互四濒。如果你需要進(jìn)行應(yīng)用程序和其他應(yīng)用間的交互測試 — 可以使用 UIAutomater换况。但是通常情況下职辨，你可以通過 Android Instrmentation 模擬這類交互并進(jìn)行測試，而且這種測試無需依賴外部因素复隆。
建議：
優(yōu)先選擇 Android Instrumentation 和 Espresso拨匆。- 測試中的頁導(dǎo)向架構(gòu)會幫助你更加方便快捷地編寫和維護(hù)程序（比如姆涩，當(dāng)你有一個描述應(yīng)用的屏幕或部分屏幕的 Page 類時）挽拂。
- 與后端模擬交互會完全孤立測試程序，進(jìn)而并行運行測試骨饿，但同時也要確保不要共享測試間的狀態(tài)亏栈。推薦 MockWebServer，非常好用宏赘。
- 開發(fā)者應(yīng)該編寫功能測試绒北，是的，你沒看錯察署。
- 教 QA 團(tuán)隊編寫功能測試 — 通常 QA 們和開發(fā)者想的不一樣闷游，并知道需要檢查什么樣的情況。
- 檢查功能測試的代碼覆蓋率贴汪。
Fail early：在 CI 中運行功能測試脐往，如果一些測試失敗的話，則放棄構(gòu)建項目扳埂。
7. 集成測試
是的业簿。依舊是測試。通常情況下阳懂，集成測試檢查應(yīng)用程序的不同組件如何協(xié)同工作梅尤，包括：HTTP 層、REST API 層和執(zhí)行層（RxJava 等）等等岩调。
設(shè)想一個使用了一堆其他類的類巷燥，它從后端加載數(shù)據(jù)，然后進(jìn)行處理并存儲在數(shù)據(jù)庫中号枕。雖然你應(yīng)該先用單元測試覆蓋每個類缰揪，但是，你也可以用集成測試來覆蓋這種成分復(fù)雜的測試堕澄。
此處邀跃，與單元測試最主要區(qū)別在于，你并不是在使用模擬環(huán)境蛙紫，而是對象在測試中的真實實現(xiàn)拍屑。你可以模擬數(shù)據(jù)傳輸（MockWebServer）和數(shù)據(jù)庫狀態(tài)，然后運行真實代碼坑傅，看看它們?nèi)绾喂ぷ鳌?/p>
你可以在 Android Instrumentation 或 JVM 的設(shè)備/模擬器上運行集成測試僵驰，因為在 JVM 上的測試運行更快 — 筆者更喜歡 JVM。
Fail early：在 CI 中運行集成測試，如果有部分測試失敗的蒜茴，則盡早放棄項目星爪。
8. 開發(fā)人員設(shè)置菜單（又名：調(diào)試抽屜）
調(diào)試版本中的開發(fā)人員設(shè)置菜單允許你啟用/禁用 Sthetho、LeakCanary 和 TinyDancer 之類的工具粉私，模擬/改變一些應(yīng)用程序的行為等等顽腾。
在應(yīng)用運行時更改和檢查應(yīng)用程序，而無需改寫代碼诺核，會為你和 QA 團(tuán)隊節(jié)省大量時間抄肖。
Fail early： LeakCanary 這樣的工具可以幫助你收到真實用戶發(fā)來的崩潰報告之前，偵測到問題所在窖杀。教你的 QA 團(tuán)隊使用類似的工具漓摩，在每次發(fā)版前進(jìn)行驗收測試。
That's it.
正文完入客。
請考慮你的開發(fā)文化管毙，并和團(tuán)隊成員討論這個話題，如此一來桌硫，你們正在打造的開發(fā)流程和產(chǎn)品質(zhì)量都可能得到顯著改善夭咬。
QualityMatters app
所以，你是不是想看看遵循以上原則打造的示例應(yīng)用呢鞍泉？點擊此處下載 Jake Wharton 遵循以上原則打造的 U2020皱埠。以下是令一波遵循了以上原則的 QualityMatters app。
希望你能發(fā)現(xiàn)一些新意：
- 單元測試咖驮；
- 集成測試边器；
- 功能測試；
- 靜態(tài)代碼分析托修；
- 代碼覆蓋率忘巧；
- 開發(fā)人員設(shè)置菜單；
- MVP睦刃、RxJava砚嘴、Dagger 2 和 Retrofit 2 等等。
QualityMatters app 將會一直維護(hù)更新下去涩拙。
一封致 Google 的公開信
正如之前所說际长，#質(zhì)量 > #表現(xiàn)
- 請多發(fā)些關(guān)于測試的內(nèi)容！
- 請測試（單元測試兴泥、集成測試和功能測試）庫和示例應(yīng)用程序工育。
- Android 需要的是 Simulator，而不是 Emulator搓彻，因為 Robolectric…雖然毋庸置疑如绸，非常有用嘱朽，但應(yīng)該有更好的辦法。
- Google 與開發(fā)社區(qū)結(jié)合怔接，可以改進(jìn) Android 開發(fā)的文化氛圍搪泳。
所以，我們需要 Android 開發(fā)文化扼脐！
相關(guān)閱讀：
- Enabling Android Teams: Tests? Ain't Nobody Got Time For That! by Ty Smith
- Android Testing (Android Dev Summit 2015)
- Droidcon NYC 2015 - Debug Builds: A New Hope
- Insights on Scaling Android Development from Cyanogen, Amazon, Twitter, Square, Eventbrite, and more
原文地址：http://artemzin.com/blog/android-development-culture-the-document-qualitymatters/
OneAPM Mobile Insight 岸军，監(jiān)控網(wǎng)絡(luò)請求及網(wǎng)絡(luò)錯誤，提升用戶留存谎势。訪問 OneAPM 官方網(wǎng)站感受更多應(yīng)用性能優(yōu)化體驗凛膏，想閱讀更多技術(shù)文章杨名，請訪問 OneAPM 官方技術(shù)博客脏榆。
本文轉(zhuǎn)自 OneAPM 官方博客
