【问题标题】:How Do We Inherit Test Classes Across Android Library Modules?我们如何跨 Android 库模块继承测试类?
【发布时间】:2016-05-06 18:00:20
【问题描述】:

我有一个带有两个库模块的 Android Studio 项目:foo-modulebar-module。每个都实现了一个库,foo-module 定义了一个策略接口,bar-module 依赖于foo-module 并实现了这样一个策略。 foo-module 有仪器测试 (foo-module/src/androidTest/) 来测试其核心代码,使用存根策略实现,bar-module 应该有自己的仪器测试。

我在foo-module/src/androidTest/ 中定义了一个AbstractTests 类,它完成了大部分实际测试。我在foo-module/src/androidTest/ 中还有一个StubTests 类,它扩展了AbstractTests 并实现了必要的abstract 方法来完成测试用例(提供策略的实现等)。这一切都很好。

bar-module/src/androidTest/ 中,我创建了一个BarStrategyTests 类,旨在镜像StubTests,但提供在bar-module 中实现的策略。但是,BarStrategyTests 看不到AbstractTests,即使我的build.gradle 文件中有compile project(':foo-module'),并且bar-module 中的主要(非测试)类可以与主要(非测试)类一起正常工作在foo-module。 IOW,虽然 project() 依赖项处理常规代码,但它不处理 androidTest/ 代码。我收到“错误:com.commonsware.foo.test 包不存在”。

我也尝试添加androidTestCompile project(':foo-module'),结果相同。

在模块之间共享仪器测试代码的秘诀是什么?

暂时,我可以克隆AbstractTests,但这不是一个很好的长期解决方案。

This SO question 涵盖了普通 Java 的类似基础。有没有人尝试过the one answer 中的选项并让它们用于 Android 仪器测试?第一个选项(将通用测试代码作为常规非测试代码移动到另一个模块中)似乎是合理的,但我不知道其他两个是否可以与com.android.library 插件而不是java 插件一起工作。

【问题讨论】:

  • 您找到实现这一目标的方法了吗?我想让我的测试类也可用于其他模块,但难以共享资源。
  • @karate:我正在使用已接受答案中概述的方法。
  • 应该有更好的方法来做到这一点,而不是将所有测试类移动到他们自己的模块并从它们扩展:( 负责 gradle 的人应该让我们更容易扩展测试类
  • Android + Kotlin 项目解决方案:stackoverflow.com/a/63298267/12001093

标签: android android-gradle-plugin


【解决方案1】:

由于所有测试类(单元和仪器)都不是任何模块(包括 aar)的一部分,因此它们不能通过依赖于该模块获得。我也遇到了这个问题,并通过创建test-module 并将所有必需的类放入其中(src/main/java)来解决它。 因此,在您的情况下,您可以在此模块中移动 AbstractTests 并将此模块用作 androidTestCompile 依赖项。

【讨论】:

  • 如果我依赖于预打包的 AAR(例如存储库工件),我绝对可以看到需要做一些不同的事情。我曾预计compile project(':foo-module') 会匹配适当的源集——毕竟,它不是compile projectButJustTheMainSourcesetPlease(':foo-module')。 :-) 我将把它打开一段时间,看看是否有其他人有其他选择,但如果你的选择最终成为最佳选择,我不会感到震惊。感谢您的帮助!
  • 请注意,这种方法似乎需要多个附加模块。基本上,foo-module 不能有自己的任何测试。不仅AbstractTests 必须移动到foo-module-test-common,而且以前在foo-module 中的任何测试都必须移动到foo-module-test。否则,你会得到循环依赖:foo-modulefoo-module-test-common 上有androidTestCompile,在foo-module 上有compile。因此,foo-module 不能依赖于 foo-module-test-common。多么痛苦。
  • 好吧,你必须避免 foo-module 依赖于 foo-module-test-common。一种选择是将所有测试从foo-module 移动到foo-module-test-common,因此该模块不仅包含src/main/java 中的常见测试类,还包含src/androidTest/javafoo-module 的测试。
  • 啊,好点子。我没想过这种组合。再次感谢!
  • @CommonsWare 你能想出一个合适的解决方案吗?我面临着类似的问题,但是我想要跨模块继承的“基础”测试工具依赖于来自org.junit.* 的东西(例如测试规则),这些东西在main/java 中不起作用...跨度>
猜你喜欢
  • 1970-01-01
  • 2017-03-07
  • 1970-01-01
  • 2016-04-14
  • 2018-02-25
  • 1970-01-01
  • 1970-01-01
  • 2016-07-22
  • 2018-05-23
相关资源
最近更新 更多