Como impedir a execução de testes instrumentados Gradle na desinstalação do aplicativo?

8

Se eu:

Crie um novo projeto do Android Studio 3.5.1 (Kotlin, API 21, modelo "Atividade vazia")
Execute o aplicativo de dentro do IDE
Confirme se o aplicativo está instalado e possui um ícone do iniciador
Execute a connectedAndroidDebugTesttarefa Gradle (de dentro do Android Studio ou via gradlew)

O aplicativo acaba sendo desinstalado pela execução do teste. Eu recebo esse comportamento mesmo se eu adicionar um testApplicationIdvalor defaultConfigpara que o código de teste use um ID de aplicativo diferente.

Como eu paro esse comportamento? Como posso executar testes instrumentados na linha de comando, sem atrapalhar a instalação de um aplicativo existente?

android android-gradle-plugin

— CommonsWare
fonte

2

Semelhante a este stackoverflow.com/questions/47670066/... (eles não conseguiram uma solução, apenas algumas soluções alternativas)

— Tyler V

@TylerV: O problema é que eu juro que não fez isso há um ano. Uso uma tarefa Gradle para um relatório de cobertura unificado (mesclando a saída de testes instrumentados e testes de unidade). Eu estava usando isso em um projeto há um ano e não me lembro de ter encontrado esse problema. Acabei de implementar o relatório novamente em um novo projeto e agora estou vendo o problema de desinstalação. É possível que minha memória do que aconteceu há um ano seja confusa, mas desinstalar um aplicativo que requer autenticação seja irritante, então eu gostaria de pensar que me lembraria.

— CommonsWare

Se eu clicar com o botão direito do mouse em um arquivo de teste individual e executá-lo dessa maneira, ele também não desinstalará o aplicativo quando terminar (eu faço isso algumas vezes para carregar alguns dados pré-preenchidos no aplicativo). É provavelmente uma etapa adicional na tarefa de teste conectado ...

— Tyler V

2

A connectedChecktarefa tem o tipo DeviceProviderInstrumentTestTask. Para um teste simples executado em um dispositivo, ele usa a SimpleTestRunner, que por sua vez usa a SimpleTestRunnablepara realmente executar o teste. Aqui você encontra uma estrutura 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
}

Não tenho muita certeza se encontrei as implementações mais recentes, mas esse comportamento exato data de vários anos. Então eu acho que você não pode conseguir o que está pedindo.

— tynn
fonte

3

Talvez tente executá-lo via adb dessa maneira:

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

Não desinstalará seu aplicativo.

aqui está descrito em mais detalhes.

— Pavlo Ostasha
fonte

1

Isso pode ser prático em algumas situações. No meu caso, a tarefa que realmente quero executar é a createDebugCoverageReportqual depende connectedAndroidDebugTest. Então, não posso evitar connectedAndroidDebugTest, com alguma reescrita de alguma forma createDebugCoverageReport.

— CommonsWare

No link para a documentação oficial que forneci na resposta, há uma lista de am instrumentopções de comando adb possíveis com as quais você pode usar am instrument. E você pode executar um relatório de cobertura via adb com a ajuda da emmaopção definida como true. Também é possível alterar um arquivo de destino do relatório de cobertura com a ajuda da coverageFile opção Espero que ajude.

— Pavlo Ostasha 07/11/19

"E você pode executar um relatório de cobertura via adb com a ajuda da opção emma definida como true". - AFAIK, o Android não usa cobertura de ema há anos, depois de ter mudado há muito tempo para Jacoco. Suponho que eles poderiam ter mantido o nome da opção o mesmo enquanto mudavam a implementação ...

— CommonsWare

Talvez - eu não conheça os detalhes. Mas existe essa possibilidade.

— Pavlo Ostasha 07/11/19

2

A instrumentação instala 2 APKs: o APK em teste e o APK com o código de teste.

Ele também desinstala os dois APKs antes de tentar instalar os novos e não sei se é possível impedir a desinstalação.

testApplicationIdaltera apenas o ID do aplicativo no APK com o código de teste (normalmente o mesmo do APK principal com ".test" anexado). O ID do aplicativo no APK em teste permanece o mesmo. Mas é possível criar buildType separado para o APK em teste (com exatamente a mesma configuração do tipo de compilação de depuração) e usá-lo.

Então connectedAndroidXYZTestpoderia ser usado para executar os testes (ou createXYZCoverageReport).

— Josef Adamcik
fonte

1

Estou aceitando a resposta de tynn, porque é a mais precisa para a pergunta. Estou oferecendo a você a solução mais segura possível ... supondo que seu código não tente fazer nada em tempo de execução com base no tipo de compilação. Se isso acontecer, você precisará se lembrar de manter o XYZtipo de construção em mente com esse código.

— CommonsWare

@CoommonsWare está correto. Normalmente evito verificações diretamente para o tipo de compilação e uso uma diretiva "buildConfigField" no gradle para gerar sinalizadores booleanos (ou o que melhor se adapte ao problema) na BuildConfigclasse.

— Josef Adamcik 08/11/19