淺談 Android 開發文化

Hello，親愛的讀者朋友們（但願大家是 Android 開發者，或者正在成爲 Androider 的路上…）！

質量從用戶反饋很清涼而後咱們就只能看 CPU 原來的想法是可是事實上不是這些可是咱們能夠把數據收集上來，從長遠角度來講，咱們呢很簡單，怎樣擺脫這種要辭職的想法，那我能去哪，要幹啥，任何團隊都有必定的問題，若是他走，我以爲我還能夠接受缺一個告警什麼叫咱們的團隊當時是

Android 開發如今陷入了困境（快陷入七年了…）。大部分程序都沒有測試功能（單元測試、集成測試和功能測試）；也都忽略了編譯和 lint 警告；而且代碼都看起來像意大利麪（希望是有反應的意大利麪…）等等等等。

壞消息：在 Android 開發文化的源頭， Google 就直接參與了這一切。

#質量爲王

是的，Google 以#執行爲王著稱，但#質量爲王實際上是更應該先作到的重要事項。

對質量水平不高的代碼進行優化，會形成不成熟的優化，而不成熟的優化也被成爲萬惡之源（雖然並不是絕對，但大多狀況下是這樣的）。

好消息：像 Square、SoundCloud、Twitter 這樣的企業和一些開發者正經過發表演講、撰寫博客，讓 Android 開發變得更好，感謝他們！此外， Google 彷佛終於對提升 Android 應用程序的質量產生興趣了！近期， Google 參加了 Android 開發峯會（AndroidDevSummit）和一些其餘會議，咱們看到了一些關於測試的內容，請繼續保持！

如今是時候來提升 Android 開發的質量了。

##Android 開發文化暨說明文檔。

###0. Fail fast 機制：儘快宕機，儘早放棄。

爲何這麼說呢？— 由於你要在產品到達用戶以前找到問題，那麼越快、越早的宕機，對你就越有利，其實這也是你該作的。

本文每一項都會遵循這個基本原則。

###1. Pull 請求、代碼審覈和持續集成

項目開發應該在版本控制系統內完成。開發過程應該經過Pull請求（如下全文簡稱 PRs），並通過代碼審覈，不然任何代碼都不能直接推送到主開發分支上。每次 PR 會應該觸發持續集成（如下全文簡稱 CI）系統，並構建項目。構建應該是可重複的，每個隊伍裏的成員都應該能夠輕鬆地構建項目。

Fail early：若是 PR 的構建在 CI 系統中失敗了，在修復完成以前，PR 不要進行合併。

###2. 代碼質量

你的代碼應該是堅實的 或者結實的。如何作到這一點，徹底取決於你本身。代碼質量並不僅和 MVP/MVVM/MVC 有關，同時也和 App 中每一個組件的每一行代碼有關。筆者更傾向使用純函數和不可變對象。

Fail early：不要成爲項目中惟一編寫可維護的代碼的開發者，確保其餘成員也能夠寫高質量的代碼（和他們聊天，一塊兒討論本文便可激勵他們！），從而防止審覈時出現糟糕的代碼。

###3. 靜態代碼/資源分析

靜態代碼分析讓你在進入生產環境以前找到代碼中的問題。同時，也對代碼審覈大有裨益。好比使用 Android Lint、FindBugs、PMD、SonarQube 和 FB Infer 等工具。

Fail early：在 CI 中運行靜態分析，安裝配置後，若是項目中出現警告（不只僅是錯誤信息），儘早放棄項目。

###4. 單元測試

是的！是測試沒錯！單元測試一般會檢查某個函數/對象是否正確地完成它的工做。項目裏的測試越多，代碼覆蓋率越高， App 在發佈後的性能，會更好更穩定。事實上，單元測試能夠發現大多數愚蠢的 bug。固然，若是你的 App 會進行數據處理的話，單元測試還將幫助你保證代碼工做正常。

Android 項目單元測試的簡易指南

1. 筆者傾向於在 JVM 上運行單元測試，由於它比在設備/模擬器上運行快得多。

2. Android 的 Gradle 插件能夠運行在JVM上的單元測試。只要把測試加至 test/ java_or_other_lang 便可。

3. 你能夠從 IDE 運行測試（右鍵點擊測試->運行）或者從 ./gradlew test 終端。

4. 你很快就會發現，若是在 JVM 運行單元測試，Android SDK 的類會被清除，觸發他們時會拋出異常。這當然可悲，可是是可修復的。若是須要 Android SDK 類的話，能夠在 Robolectric 測試運行器下運行，Robolectric 提供了大部分實現 Android SDK 類的方法。

5. JUnit 提供了很棒的測試工具和至關不錯的 Rules 概念，可是 JUnit 的斷言很很差用。 AssertJ 和 Truth 等工具對斷言的支持很好，而且能夠在 JUnit （或 TestNG/Spock 等）下運行。

6. 若是你須要檢查行爲和複製某些對象，你可使用 Mockito 之類的複製庫。

TDD 與否，取決於你，但絕對值得一試！

Fail early: 在 CI 中運行單元測試，若是有一些測試失敗了，則儘早放棄。

###5. 代碼覆蓋率

一旦開始編寫單元測試，你便須要知道代碼覆蓋率是否足夠好。 像 Jacoco 這樣的工具能夠幫助你檢查測試程序所走的代碼路徑。若是你測試的代碼表現依賴於條件語句，代碼覆蓋率就尤其重要，由於你須要確保代碼執行中的全部可能都獲得檢查。

你能夠經過apply plugin: ‘jacoco’語句啓用 Jacoco。你能夠經過jacocoReport Gradle 任務配置哪些類/包應該被檢查。

若是覆蓋率不夠高，配置代碼覆蓋工具使之放棄構建項目。若是你剛剛開始在一個已存在的項目中使用單元測試，除了非測試類，一旦測試代碼能夠覆蓋這些類，就將它們從排除列表中刪除。這個規則能夠保證新代碼的覆蓋率。根據覆蓋報告，你可使用 jacoco-coverage 插件放棄構建。

Fail early：確保在 CI 環境中檢查代碼覆蓋率，若是代碼覆蓋率不夠高，儘早放棄構建。

###6. 功能（UI）測試

沒錯！更多的測試。功能測試會從用戶的角度檢查 APP 的功能。功能測試啓動應用程序後，會驗證某些功能，好比在 UI 界面中加載出的數據是否正確顯示。QA 團隊進行的大部分工做能夠經過功能測試達到自動化，但這並不意味着你不須要 QA 團隊。

運行功能測試有兩種基本的方法，在 Android Instrumentation 或 UIAutomator 裏運行。最主要的區別是，在 Android Instrumentation 裏運行功能測試時只能與應用程序交互，並能夠接觸到程序代碼。在 UIAutomator 裏進行的測試會運行在系統進程中，並經過Accessibility API（相比於 Android Intrumentation，此方式的功能十分有限）和應用程序進行交互。若是你須要進行應用程序和其餘應用間的交互測試 — 可使用 UIAutomater。可是一般狀況下，你能夠經過 Android Instrmentation 模擬這類交互並進行測試，並且這種測試無需依賴外部因素。

建議：

• 優先選擇 Android Instrumentation 和 Espresso。

• 測試中的頁導向架構會幫助你更加方便快捷地編寫和維護程序（好比，當你有一個描述應用的屏幕或部分屏幕的 Page 類時）。
• 與後端模擬交互會徹底孤立測試程序，進而並行運行測試，但同時也要確保不要共享測試間的狀態。推薦 MockWebServer，很是好用。
• 開發者應該編寫功能測試，是的，你沒看錯。
• 教 QA 團隊編寫功能測試 — 一般 QA 們和開發者想的不同，並知道須要檢查什麼樣的狀況。
• 檢查功能測試的代碼覆蓋率。

Fail early：在 CI 中運行功能測試，若是一些測試失敗的話，則放棄構建項目。

###7. 集成測試

是的。依舊是測試。一般狀況下，集成測試檢查應用程序的不一樣組件如何協同工做，包括：HTTP 層、REST API 層和執行層（RxJava 等）等等。

設想一個使用了一堆其餘類的類，它從後端加載數據，而後進行處理並存儲在數據庫中。雖然你應該先用單元測試覆蓋每一個類，可是，你也能夠用集成測試來覆蓋這種成分複雜的測試。

此處，與單元測試最主要區別在於，你並非在使用模擬環境，而是對象在測試中的真實實現。你能夠模擬數據傳輸（MockWebServer）和數據庫狀態，而後運行真實代碼，看看它們如何工做。

你能夠在 Android Instrumentation 或 JVM 的設備/模擬器上運行集成測試，由於在 JVM 上的測試運行更快 — 筆者更喜歡 JVM。

Fail early：在 CI 中運行集成測試，若是有部分測試失敗的，則儘早放棄項目。

###8. 開發人員設置菜單（又名：調試抽屜） 調試版本中的開發人員設置菜單容許你啓用/禁用 Sthetho、LeakCanary 和 TinyDancer 之類的工具，模擬/改變一些應用程序的行爲等等。

在應用運行時更改和檢查應用程序，而無需改寫代碼，會爲你和 QA 團隊節省大量時間。

Fail early： LeakCanary 這樣的工具能夠幫助你收到真實用戶發來的崩潰報告以前，偵測到問題所在。教你的 QA 團隊使用相似的工具，在每次發版前進行驗收測試。

That's it. 正文完。

請考慮你的開發文化，並和團隊成員討論這個話題，如此一來，大家正在打造的開發流程和產品質量均可能獲得顯著改善。

###QualityMatters app

因此，你是否是想看看遵循以上原則打造的示例應用呢？點擊此處下載 Jake Wharton 遵循以上原則打造的 U2020。如下是令一波遵循了以上原則的 QualityMatters app。

但願你能發現一些新意：

• 單元測試；
• 集成測試；
• 功能測試；
• 靜態代碼分析；
• 代碼覆蓋率；
• 開發人員設置菜單；
• MVP、RxJava、Dagger 2 和 Retrofit 2 等等。

QualityMatters app 將會一直維護更新下去。

一封致 Google 的公開信

正如以前所說，#質量 > #表現

• 請多發些關於測試的內容！
• 請測試（單元測試、集成測試和功能測試）庫和示例應用程序。
• Android 須要的是 Simulator，而不是 Emulator，由於 Robolectric…雖然毋庸置疑，很是有用，但應該有更好的辦法。
• Google 與開發社區結合，能夠改進 Android 開發的文化氛圍。

因此，咱們須要 Android 開發文化！

相關閱讀：

• 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 ，監控網絡請求及網絡錯誤，提高用戶留存。訪問 OneAPM 官方網站感覺更多應用性能優化體驗，想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客