浅谈 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 官方博客