¿Cómo heredamos clases de prueba en los módulos de la biblioteca de Android?

android-gradle-plugin

Question

Tengo un proyecto de Android Studio con dos módulos de biblioteca: foo-module y bar-module . Cada uno implementa una biblioteca, con foo-module define una interfaz de estrategia y bar-module dependiendo de foo-module e implementando dicha estrategia. foo-module tiene pruebas de instrumentación ( foo-module/src/androidTest/ ) para probar su código central, usando una implementación de estrategia de stub, y bar-module debe tener sus propias pruebas de instrumentación.

foo-module/src/androidTest/ una clase de AbstractTests en foo-module/src/androidTest/ que hace la mayoría de las pruebas reales. También tengo una clase StubTests en foo-module/src/androidTest/ que extiende AbstractTests e implementa los métodos abstract necesarios para completar el caso de prueba (proporcionando una implementación de la estrategia, etc.). Todo esto funciona muy bien.

En bar-module/src/androidTest/ , creé una clase BarStrategyTests , diseñada para reflejar StubTests , pero proporciona la estrategia implementada en bar-module . Sin embargo, BarStrategyTests no puede ver AbstractTests , aunque BarStrategyTests compile project('':foo-module'') en mi archivo build.gradle , y las clases principales (non-test) en bar-module pueden funcionar bien con main (non- test) clases de test) en foo-module . IOW, mientras que la dependencia project() maneja código regular, no maneja androidTest/ code. Recibo "error: el paquete com.commonsware.foo.test no existe".

También intenté agregar el androidTestCompile project('':foo-module'') , con el mismo resultado.

¿Cuál es la receta para compartir el código de prueba de instrumentación entre módulos?

Temporalmente, puedo clonar AbstractTests , pero esa no es una gran solución a largo plazo.

Esta pregunta de SO cubre un terreno similar para Java ordinario. ¿Alguien ha probado las opciones en la respuesta y las ha hecho funcionar para las pruebas de instrumentación de Android? La primera opción (mover el código de prueba común a otro módulo como código regular sin prueba) parece plausible, pero no tengo idea si los otros dos funcionarán bien con el complemento com.android.library lugar del complemento java .

Answer 1

Debido al hecho de que todas las clases de prueba (unidad e instrumentación) no son parte de ningún módulo, incluso aar, no están disponibles a través de la dependencia de ese módulo. También enfrenté este problema y lo resolví creando test-module y puse todas las clases requeridas en él ( src/main/java ). Entonces, en su caso, puede mover AbstractTests en este módulo y usar este módulo como una dependencia de androidTestCompile .