来自Unsplash的“管道”照片
一般方法
你好 我将在开发中的管道上发表一系列文章，不仅是帮助验证正在开发的移动应用程序的质量。 主要思想是强调当前与移动相关的所有方法：针对Android和iOS的本地开发，React Native，Xamarin和Flutter。 我将从Android开始，但首先我想对这一切有一个大致的了解。
请记住，这是在开发Android应用程序时可能会用到的工具和实践的一般概述，而不是有关如何配置这些工具的教程。
这是做什么用的？
让我们从一个众所周知的事实开始：越晚发现应用程序中的缺陷，修复它的成本就越高。 假设您已经发现生产中的错误。 您的测试人员需要在本地重现此错误，对其进行注册，确定优先级，将其传递给开发人员，然后他们又需要对其进行修复，制作一个新的程序集，然后将其传送回测试人员，以使他们确信所有问题都已修复，然后进行发行版本的构建，以及然后将新版本发送给用户。
如果您从一开始就具有防止出现错误的机制，那么可以节省许多时间。 我并不是说有消除所有错误的灵丹妙药-这是不可能的。 但是，可能的是建立障碍（也称为质量门），以增加尽早发现代码中的错误的可能性。
在开发人员的计算机上
作为开发人员，您始终使用IDE和命令行工具在计算机上工作。 让我们来看看对于Android开发人员而言存在什么。
Android Studio
现在，这是Android开发人员的默认选项，并且由于它基于IntelliJ平台，因此对Java，Kotlin和XML进行了许多检查。 我建议您在团队中就要使用的特定规则达成一致，在一台计算机上对其进行配置，然后将包含这些规则的settings.jar文件上传到您的版本控制系统或某种协作性工作工具（例如Confluence）。
Android Studio中的检查设置
AS还具有可通过按Alt + Enter应用于代码的快速修复。
Android Studio的快速修复示例
Android Lint
这是一个专门用于Android开发的静态分析工具，提供了数百条规则，您可以使用任何规则。 Lint也可以从Gradle任务（任务）启动，并直接在Android Studio中给出提示，并生成报告。 它具有许多检查，分为类别-安全性，国际化，可用性，性能...
但是添加自己的规则的能力使其功能特别强大。 例如， Room有其自己的规则集， Timber日志记录库有其自己的规则。 您可以为团队或项目创建规则，并确保没有人犯某些典型的错误。 （顺便说一下，即将在Mobius会议上发表有关此方面的报告 ，解释了理论方面和实践方面）。
Android Lint报告示例
更多静态分析
当然，有许多静态分析工具不是专门为Android设计的，而是通常为Java和Kotlin设计的 ： PMD ， FindBugs （已放弃，使用SpotBugs ）， Checkstyle ， Ktlink ， Detekt等。 选择您喜欢的方式，将其集成到您的管道中并确保其实际使用（精确度如何？
来自FindBugs的报告示例
但是，仅仅拥有一个提供需要修复的数据的工具还不够。 您还将发现以下有用信息：
- 测试的代码覆盖率随时间如何变化？
- 我要花多长时间才能解决所有发现的问题？
- 项目中有多少重复代码？
- 如何将规则扩展到多个团队？
还有许多其他。 在EPAM Systems，我们注重质量，因此我们选择SonarQube作为回答这些问题的工具。 有关SonarQube的其他好处，请单击此处 。
单元测试
希望您不必因为各种原因再次保证该死的代码需要单元测试。 遵循TDD，遵循测试金字塔的原理或测试蘑菇的新概念都没关系。 将覆盖范围设置为目标并不重要，无论如何，单元测试是必要的组成部分。 因此，您需要编写和运行它们！ 幸运的是，经过11年的发展，我们从Gradle和Android Gradle插件中获得了一种非常方便的运行测试机制。
在Android项目中，默认项目具有testDebugUnitTest任务（当然，对于您来说，它可能因口味而异），由她来运行测试。 确保使用它，并且代码覆盖率随着时间的推移而增加。 Java单元测试的优点是它们可以在JVM工作站上运行，而不是在Dalvik / ART上运行，这在速度上具有优势。
在android单元测试的情况下，存在一个基本问题：对Android SDK的依赖。 这就是为什么所有这些UI层方法都像MVP，MVVM，MVI和其他MV *出现的原因之一。 取决于Android上的类的具体问题是，单元测试只是由于使用了这个Android本身的存根而导致下降，而存根只是引发了异常。 当然，有两种选择：要么跳过此类的测试，要么将某些逻辑提取到其他类中，或者为依赖于Android的类创建接口以测试一些高级逻辑，或者使用Robolectric（这远非理想）。 另一种选择是使用仪器化测试，该测试可能适用于检查活动的行为，但是当前的趋势是活动不应包含测试。
关于覆盖率问题：您想知道当前情况以及它随时间的变化，因此您也将需要一个工具。 据我所知， jacoco是Java的行业标准，并且具有Kotlin支持。
仪器测试
这些测试在Android模拟器上运行，从而允许他们使用Android框架。 不幸的是，它们运行缓慢且不稳定（由于仿真器存在一些问题），因此我所知的大多数开发人员都亲自避免使用它们。 但是它们在Gradle和Android Studio中提供支持，因此对于您来说，它们可能是合适的。
安全审核
除了简单的错误，错别字，复制粘贴问题等外，您还应注意一大类问题：安全性。 当然，Android Lint已经提供了一些相关提示，但是最好使用专门用于此任务的专用工具。 这些工具可以在静态和动态模式下工作。 根据您的安全要求，您可能要使用这两种模式，或同时使用这两种模式。 例如，您可能想从Mobile Security Framework开始 ，然后再考虑付费选项。
幸运的是，这里有一系列由OWASP直接编译的静态分析工具。 例如，您可以选择Find Security Bugs或使用OWASP SonarCube Project 。
验证验证
正如我所说，反馈周期越短，您花费在修复错误上的时间和金钱就越少。 因此，我想确保代码与生产质量相对应，甚至可以到达存储库甚至在本地进行通信。 当然，您可以简单地要求开发人员执行检查，但是还有一个更好的选择：Git挂钩。
我建议为我们上面讨论的所有检查添加一个预提交钩子：lint，静态代码分析和单元测试。 可以在此处找到设置过程的示例。
CI / CD管道
很难想象没有CI / CD管道的Android项目。 您的目标是在组装阶段重复上述所有检查。 这有几个原因：
- 使用--no-verify选项可以轻松绕开Git挂钩
- 该代码可以在本地成功通过所有检查，但是在合并后会引入问题
- 需要测试和覆盖率报告
bitrise.io上的报告示例
幸运的是，您只需要在Gradle构建脚本中直接提及这些安全检查，或者在CI / CD管道中调用相应的任务。 如果您在构建管道方面遇到困难，我最近在2019年关于移动DevOps的DevOops会议上做了演讲 。
还请执行以下操作：
- 运行所有检查请求请求。 不要让任何违反任何规则的请求合并。 这非常重要：如果不执行该规则，那么实际上它不存在。
- 在组装和部署期间运行所有检查。 您不想降低质量标准。
- 如果构建被破坏，这是第一要务。 团队应立即解决问题，因为这违反了您的持续交付惯例，并阻止了团队编写质量代码。
祝您好运，改善您的代码！
如果您喜欢本文，请在Twitter上关注我，以免您错过以下内容。 而且，如果您将于12月在莫斯科举行，或者可以参加，请参加我们的Mobius会议，了解有关Android（和iOS）开发的许多其他信息！
PS感谢vixentael处理安全问题，感谢Alexei Nikitin进行审查和评论，感谢Alexander Bakanov进行校对。