java - 在 Android 仪器测试中模拟资源

Question

我想用真实设备测试程序库调用的效果。此调用启动一项服务，该服务向服务器发送 HTTP 请求，该服务器的 URL 硬编码在资源中。

我想验证请求是否正确发送。所以我设置了一个本地 HTTP 服务器，但为了能够使用它，我必须更改/覆盖/模拟资源，使其指向 http://127.0.0.1。

我想做“端到端”测试；在这种情况下，重要的是服务发出实际的网络请求，尽管是在本地。

我试图通过在 androidTest/res/values/strings.xml 中创建同名的字符串资源来覆盖该值，但该资源仅在测试包中可见，而不是在应用程序包中。

使用Instrumentation 类只允许我获取Context 引用，但没有办法替换它(或getResources()< 的返回值) 与模拟或类似的东西。

如何更改被测应用程序的资源值？

Answer 1

你有几个选择:

• 依赖注入(inject)
• stub /模拟
• 共享首选项
• 脚本或 gradle 任务

依赖注入(inject)

使用像 RoboGuice 或 Dapper 这样的库。注入(inject)处理 API 请求的对象。然后，在您的测试设置中，您可以用测试版本替换注入(inject)模块。这样你的测试代码就可以运行，而不是原来的；该代码可以传入不同的字符串(硬编码或来自测试 strings.xml)。

DI 库的设置成本很高:学习曲线高，如果使用不当可能会出现性能问题。如果对象的范围/生命周期配置不正确，甚至会引入难以调试的问题。如果测试是使用 DI 的唯一原因，如果您对 DI 容器不满意，那么它可能不值得。

stub /模拟

在实现您编写的自定义界面的东西中结束您的调用。然后，您的主要实现会填写主机 URL 并调用 API。然后，在测试中，在该接口(interface)上使用 stub 或模拟的组合来替换填充主机 URL 部分的代码。

这不是集成测试，因为 stub 或模拟将替换部分代码。但是比设置依赖注入(inject)框架更简单。

共享首选项

使用 Android SharedPreferences 系统。让它默认为某个端点(生产)。但允许应用程序在测试设备上启动，然后一些对话框或设置让您更改主机 URL。再次运行测试，现在它们指向不同的 API URL。

脚本或 gradle 任务

在某些场景下编译前写一些脚本或gradle task来修改源码。

这可能相当复杂，如果做得不好，甚至可能过于依赖平台或系统。系统变化可能相当脆弱。如果运行错误的命令来构建最终的打包版本并且错误的代码转换市场，则可能会引入错误。

个人意见

我推荐哪些？如果您和/或您的团队熟悉 RoboGuice 或 Dapper 等 DI 库，我推荐该选项。它是最正式、类型安全和严格的解决方案。它还保持堆栈的更多完整性以测试整个解决方案。

如果您不熟悉好的 DI 库， stub /模拟和接口(interface)包装器是一个很好的后备解决方案。无论如何，它们部分必须在 DI 解决方案中使用，并且您可以围绕它们编写足够的测试来涵盖您需要测试(并控制)的大部分情况。它非常接近 DI 解决方案，我会向所有尚未在项目中使用 DI 的人推荐它。

SharedPreferences 解决方案非常适合在暂存环境和生产环境之间切换以进行 QA 和支持。但是，我不建议将它用于自动化测试，因为该应用程序很可能在开发过程中经常被重新安装/重置，经常重置该 URL 会很烦人。此外，第一次运行的测试可能会失败； CI 服务器上的 headless 测试会失败，等等。(您可以将 URL 默认为本地主机，但随后您冒着意外将默认发布到生产环境的风险。)

我不推荐脚本或乱七八糟的 gradle 任务。太脆弱，后面的其他开发人员不太清楚，而且比他们的值(value)更复杂，IMO。