本站已关停,现有内容仅作科研等非赢利用途使用。特此声明。
查看: 1441|回复: 0
打印 上一主题 下一主题

在 Android Studio 中利用 Product flavors 进行封闭测试

[复制链接]
跳转到指定楼层
1#
发表于 2016-2-3 15:03:10 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

英文原文:Leveraging product flavors in Android Studio for hermetic testing

作者: Jose Alcérreca 和 Wojtek Kaliciński,Google 工程师。

最近,我们借助 Android 开发者峰会的机会进行了交流,期间,我们以一个简单的 Notes 应用为例,探讨了它在 Android 上的测试情况。此示例应用是我们在测试 codelab 的过程中创建的。交流过程中,我们讨论了测试不稳定(test flakiness)的问题,并引入了一个简单的解决方案,用于设置封闭测试(hermetic testing)环境。


解决测试不稳定的问题

对于利用诸如 Espresso 或 UI Automator 等框架的 UI 测试,如果应用具有外部依赖项,而且这些依赖项有时可能无法响应或者需要很长时间才能响应,那么测试会很容易变得不稳定。简而言之,不稳定测试就是指不可靠(通过测试或未通过测试都非常随机)的测试,很难实现最初进行测试的总体目标。

对此问题,一个通用解决办法就是进行封闭测试,换言之,要确保您的测试与依赖项相隔离。使用仅返回预定义数据的模拟(fake)实现或模拟服务器是处理此类问题的通用办法。下面是一些很好的示例:

  • 网络调用可以通过模拟客户端 API 或模拟服务器实现,它们会立即从存储在磁盘上的文件返回数据,而不是通过网络。这会避开网络延迟和不稳定问题,以及源自实际服务器的任何错误。
  • 与低层框架 API 的交互(特别是那些访问诸如相机或存储等硬件的 API)可以通过中间接口来传递。对接口的模拟实现不必依赖硬件,可以通过预加载数据(如图像)的引用立即返回数据。
  • 任何传感器也可模拟实现:如 GPS、麦克风、加速计等,可以测试那些在实际测试中很难获得的数据,比如预设定的位置或一组模拟的手势输入。

依赖注入 (DI) 是一种软件设计模式,为重用模块以及实现模块的可替换提供了便利。依赖注入框架可以帮助您处理与此模式相关联的样板文件,但是可能需要花费大量的时间来对其进行设置并了解它们的工作方式。在您准备好致力于将某个框架用于您的应用之前,您可能希望找到一种更为简便的方法,特别是如果您的项目需求很简单的话。

利用产品定制管理依赖项

产品定制(Product flavors)是 Android Studio 和 Android Gradle 插件的一个强大功能,允许您在编译时交换 Java 类,并且不需要额外的库。以下是一些典型的定制维度示例:

  • free/paid flavors(免费/付费版):面向不同分发渠道而生成的两个不同 APK
  • stable/experimental(稳定/实验版):在不同的源码集中保持实验功能,并快速生成 beta 版本

我们可以利用同一机制创建应用的两个独立版本,以便帮助进行封闭测试:

  • prod(产品版):使用真实的数据和资源,使用真实的服务和组件。
  • mock(模拟版):包含难以测试的依赖项的模拟实现版本。

步骤非常简单:

1. 在您的 app/build.gradle 文件中创建定制特性。

  1. android {  
  2.       productFlavors {  
  3.            mock {   
  4.                 applicationIdSuffix = ".mock"  
  5.            }  
  6.            prod  
  7.       }  
  8. }
复制代码

2. 创建两个目录:app/src/prod 和 app/src/mock

3. 在 prod/java 文件夹中创建用于生产环境代码的类,或者从 main/java 中移动过来。确保 main/java 文件夹不含此类。

4. 在 mock/java 文件中创建同一个类(具有完全一致的类名和文件名),但提供用于测试的不同(模拟)实现。

5. 在 Android Studio 中的 Build Variants 窗口中,选择要安装或再次运行测试的变体。变体是定制和构建类型的组合。

注意:在 gradle 中,当您添加定制特性时任务名称会改变。现在,您需要选择的是 installProdDebug 或 installMockDebug,而不是 installDebug 了。

运行测试

现在配好了 Prod 和 Mock 定制并且 mock 实现也就位了,您可以使用以下 gradle 任务来选择您的测试应如何运行:

  • connectedMockDebugAndroidTest:将合并 androidTest 和 androidTestMock 目录,并运行所有源码集中发现的测试。由于这些测试是以一种封闭的方式运行,因此速度更快,稳定性更高。此方式非常适合预提交(pre-submit)检查。
  • connectedProdDebugAndroidTest:将使用真实的 API 和传感器,因此可能偶尔失败。如果您有一个持续集成系统,则可以每晚执行此任务,或者作为可接受的端到端测试手工执行。请注意,此任务将在 androidTest 中运行测试,即便不存在 androidTestProd 也是如此。

您可以参考我们的 Android Testing Codelab 来查看我们如何使用此方法提供不同的 Injection 类实现,其中 prod 中的实现使用真实的数据,另一个实现 (mock) 用模拟数据执行隔离测试。

当您对封闭设置感到满意时,您可能会希望为您的构建流程提供更大的灵活性,并且增加更多维度,以便能够与您应用中的不同组件进行交换。上面讨论的方法仅适用于简单项目,对于更为复杂的情形,最好是花一些时间来了解并为您的项目添加依赖注入框架。



ChinaGDG.com
回复

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表