為什麼 Android 測試如此困難：曆史版本

<b>本文講的是為什麼 Android 測試如此困難：曆史版本，</b>

<b></b>

作為一種職業，程式員總是完全無視自己的曆史。 David West, 《Object Thinking》

在本文章中，我将推測這個問題的答案。我認為 Android 目前不理想的測試狀态由三個原因造成：性能因素、應用元件類目的不明确，以及在 Android 剛推出時 TDD 和自動化測試的不成熟。

在某種程度上，代碼的性能和可測試性是反相關的。就像 Michael Feathers 指出的那樣，可測試的代碼需要抽象層。

如同 Chet Haase 所說，抽象層有性能代價。作為 Android 開發者，我們需要對其額外警惕：

雖然 2017 年有“#perfmatters”，但性能問題在 Android 推出之初比現在更受關注。這意味着 Android API 的設計和 Android 應用的早期架構/實踐是對性能非常敏感的。添加額外的抽象層用于測試，在那段時間可能是不現實的。

我最近聽 Ficus Kirkpatrick 說了一件有趣的事。它是關于在 Android 系統設計和早期的 Android 開發中，性能因素有多重要的。Ficus Kirkpatrick 是 Android 組成立時的成員之一，他在最近某期 Android Developers backstage 中提起：

關于性能和開發速度之間的權衡，在播客中已經有了很好的讨論。Chet Haase 和 Tor Norbye 非常強調性能因素，而目前在 Facebook 工作的 Ficus Fitzpatrick 看起來更傾向于犧牲性能換取開發速度。

另一個造成 Android 測試環境如此惡劣的原因是我們可能完全誤解了 Android 的元件類（即<code>Activity</code>, <code>Service</code>,<code>BroadcastReceiver</code>, 和 <code>ContentProvider</code>）的目的。在很長一段時間裡，我以為這些類是用于友善應用開發的。Diane Hackborne 并不這樣認為：

…從它的 Java 語言 API 和相當高層的概念來看，它像是一個典型的應用架構，用于訓示應用應當如何工作。但就大部分情況而言，它不是。 大概把 Android API 稱為“系統架構”會更合适。大多數情況下，我們提供的平台 API 是用于定義一個應用如何與作業系統互動的；但對于任何從純粹在應用内部運作的東西而言，這些 API 和它并沒有什麼關系。

Chet Haase在他的 Developing for Android medium 部落格中重新強調了這一點：

有另一件事情導緻了 Android 不佳的測試狀況： TDD 和 Android 同時崛起。 Android 最初的版本是在 2008 年九月釋出的。最早的關于 TDD 型單元測試的書之一——TDD by Example，僅僅比它早 3 年。

自動化測試的重要性比那時更廣泛地被接受。測試的重要性影響了 Android SDK 的設計決策，以及 Android 社群對于支援測試的架構和實踐的熱情。

<b>原文釋出時間為：2017年2月26日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>