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 官方部落格