淺談 Android 開發文化

Hello，親愛的讀者朋友們（希望你們是 Android 開發者，或者正在成為 Androider 的路上…）！

質量從用戶反饋很清涼然后我們就只能看 CPU 原來的想法是但是事實上不是這些但是我們可以把數據收集上來，從長遠角度來說，我們呢很簡單，怎樣擺脫這種要辭職的想法，那我能去哪，要干啥，任何團隊都有一定的問題，如果他走，我覺得我還可以接受缺一個告警什么叫我們的團隊當時是

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

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

質量為王

是的，Google 以 #執行為王 著稱，但 #質量為王 其實是更應該先做到的重要事項。

好消息：像 Square、SoundCloud、推ter 這樣的企業和一些開發者正通過發表演講、撰寫博客，讓 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 開發文化！