¿Cómo evito que las ejecuciones de prueba instrumentadas de Gradle desinstalen la aplicación?

8

Si yo:

Cree un nuevo proyecto de Android Studio 3.5.1 (Kotlin, API 21, plantilla "Actividad vacía")
Ejecuta la aplicación desde el IDE
Confirme que la aplicación está instalada y tiene un ícono de inicio
Ejecute la connectedAndroidDebugTesttarea Gradle (desde Android Studio o vía gradlew)

La aplicación termina siendo desinstalada por la prueba de funcionamiento. Obtengo ese comportamiento incluso si agrego un testApplicationIdvalor para defaultConfigque el código de prueba use una ID de aplicación diferente.

¿Cómo detengo ese comportamiento? ¿Cómo puedo ejecutar pruebas instrumentadas desde la línea de comandos, sin perturbar la instalación de una aplicación existente?

android android-gradle-plugin

— CommonsWare
fuente

2

Similar a este stackoverflow.com/questions/47670066/… (no obtuvieron una solución, solo algunas soluciones)

— Tyler V el

@ TylerV: La cosa es que juro que no hizo esto hace un año. Utilizo una tarea de Gradle para un informe de cobertura unificado (fusionando el resultado de pruebas instrumentadas y pruebas unitarias). Estaba usando eso en un proyecto hace un año, y no recuerdo haber tenido este problema. Acabo de implementar el informe nuevamente en un nuevo proyecto, y ahora veo el problema de desinstalación. Es posible que mi memoria de lo que sucedió hace un año sea borrosa, pero desinstalar una aplicación que requiere autenticación es molesto, por lo que me gustaría pensar que lo recordaría.

— CommonsWare

Si hago clic derecho en un archivo de prueba individual y lo ejecuto de esa manera, tampoco desinstalará la aplicación cuando termine (a veces hago esto para cargar algunos datos previamente completados en la aplicación). Probablemente sea un paso adicional en la tarea de prueba conectada ...

— Tyler V

2

La connectedChecktarea tiene el tipo DeviceProviderInstrumentTestTask. Para una prueba simple ejecutada en un dispositivo, usa a SimpleTestRunner, que a su vez usa a SimpleTestRunnablepara ejecutar realmente la prueba. Aquí encontrarás una estructura de

try {
    // connect to device
    // install all APKs
    // run tests
} catch(Exception e) {
    // handle error
} finally {
    // get test report
    // uninstall all APKs
    // disconnect from device
}

No estoy completamente seguro de haber encontrado las implementaciones más recientes, pero este comportamiento exacto se remonta a varios años. Así que supongo que no puedes lograr lo que estás pidiendo.

— tynn
fuente

3

Tal vez intente ejecutarlo de adbesta manera:

adb shell am instrument -w com.android.demo.app.tests/android.support.test.runner.AndroidJUnitRunner

No desinstalará su aplicación.

aquí se describe con más detalles.

— Pavlo Ostasha
fuente

1

Eso podría ser práctico en algunas situaciones. En mi caso, la tarea que realmente quiero ejecutar es createDebugCoverageReport, de la cual depende connectedAndroidDebugTest. Por lo tanto, no puedo evitar connectedAndroidDebugTest, salvo reescribir de alguna manera el createDebugCoverageReport.

— CommonsWare

En el enlace a la documentación oficial que proporcioné en la respuesta, hay una lista de posibles am instrumentopciones de comando adb que puede usar am instrument. Y puede ejecutar un informe de cobertura a través de adb con la ayuda de la emmaopción establecida en true. También puede cambiar un archivo de destino del informe de cobertura con la ayuda de la coverageFile opción. Espero eso ayude.

— Pavlo Ostasha el

"Y puede ejecutar un informe de cobertura a través de adb con la ayuda de la opción emma establecida en verdadero". - AFAIK, Android no ha utilizado la cobertura de emma durante años, ya que hace mucho tiempo se cambió a Jacoco. Supongo que podrían haber mantenido el nombre de la opción igual al cambiar la implementación ...

— CommonsWare

Tal vez, no sé los detalles. Pero existe tal posibilidad.

— Pavlo Ostasha

2

La instrumentación instala 2 APK: el APK bajo prueba y el APK con el código de prueba.

También desinstala ambos APK antes de intentar instalar los nuevos y no sé si es posible evitar la desinstalación.

testApplicationIdsolo cambia el ID de la aplicación para el APK con el código de prueba (que normalmente es el mismo que para el APK principal con ".test" adjunto), el ID de la aplicación del APK bajo prueba sigue siendo el mismo. Pero es posible crear buildType por separado para el APK bajo prueba (con exactamente la misma configuración que el tipo de compilación de depuración) y usarlo.

Entonces connectedAndroidXYZTestpodría usarse para ejecutar las pruebas (o createXYZCoverageReport).

— Josef Adamcik
fuente

1

Estoy aceptando la respuesta de tynn, porque es la más precisa para la pregunta. Le estoy dando la recompensa por la solución más segura ... suponiendo que su código no intente hacer nada en tiempo de ejecución según el tipo de compilación. Si lo hace, deberá recordar tener XYZen cuenta el tipo de compilación con ese código.

— CommonsWare

@CoommonsWare eso es correcto. Por lo general, evito las verificaciones para el tipo de compilación directamente y utilizo una directiva "buildConfigField" en gradle para generar banderas booleanas (o lo que se adapte al problema) en la BuildConfigclase.

— Josef Adamcik