Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de construção com metadados do módulo, dependências de tempo de compilação e instruções de empacotamento. O Android agora usa o sistema de compilação Soong para uma configuração de teste mais simples.
Soong usa arquivos Blueprint ou .bp , que são descrições declarativas simples, semelhantes a JSON, de módulos a serem construídos. Este formato substitui o sistema baseado em Make usado nas versões anteriores. Consulte os arquivos de referência do Soong no Painel de Integração Contínua para obter detalhes completos.
Para acomodar testes personalizados ou usar o Android Compatibility Test Suite (CTS), siga a Configuração de teste complexo .
Exemplo
As entradas abaixo vêm deste exemplo de arquivo de configuração do Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Um instantâneo está incluído aqui por conveniência:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Observe que a declaração android_test no início indica que este é um teste. Incluir android_app indicaria, por outro lado, que este é um pacote de compilação.
Configurações
As seguintes configurações recebem explicação:
name: "HelloWorldTests",
A configuração name é necessária quando o tipo de módulo android_test é especificado (no início do bloco). Ele dá um nome ao seu módulo, e o APK resultante terá o mesmo nome e com um sufixo .apk , por exemplo, neste caso, o apk de teste resultante é nomeado como HelloWorldTests.apk . Além disso, isso também define um nome de destino make para seu módulo, para que você possa usar make [options] <HelloWorldTests> para construir seu módulo de teste e todas as suas dependências.
static_libs: ["androidx.test.runner"],
A configuração static_libs instrui o sistema de compilação a incorporar o conteúdo dos módulos nomeados no apk resultante do módulo atual. Isso significa que espera-se que cada módulo nomeado produza um arquivo .jar , e seu conteúdo será usado para resolver referências de caminho de classe durante o tempo de compilação, bem como incorporado ao apk resultante.
O módulo androidx.test.runner é o pré-construído para a AndroidX Test Runner Library, que inclui o executor de testes AndroidJUnitRunner . AndroidJUnitRunner oferece suporte à estrutura de testes JUnit4 e substituiu InstrumentationTestRunner no Android 10. Leia mais sobre como testar aplicativos Android em Testar aplicativos no Android .
Se você estiver criando um novo módulo de instrumentação, sempre deverá começar com a biblioteca androidx.test.runner como seu executor de testes. A árvore de origem da plataforma também inclui outras estruturas de teste úteis, como ub-uiautomator , mockito-target , easymock e muito mais.
certificate: "platform",
A configuração certificate instrui o sistema de compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso será necessário se o seu teste usar uma API ou permissão protegida por assinatura. Observe que isso é adequado para testes contínuos de plataforma, mas não deve ser usado em módulos de teste CTS. Observe que este exemplo usa esta configuração de certificado apenas para fins de ilustração: o código de teste do exemplo não precisa realmente que o apk de teste seja assinado com o certificado de plataforma especial.
Se você estiver escrevendo uma instrumentação para seu componente que reside fora do servidor do sistema, ou seja, é empacotada mais ou menos como um apk de aplicativo normal, exceto que está embutido na imagem do sistema e pode ser um aplicativo privilegiado, é provável que sua instrumentação tenha como alvo o pacote de aplicativos (veja a seção abaixo sobre o manifesto) do seu componente. Nesse caso, o makefile do seu aplicativo pode ter sua própria configuração certificate e seu módulo de instrumentação deve manter a mesma configuração. Isso ocorre porque, para direcionar sua instrumentação ao aplicativo em teste, o apk de teste e o apk do aplicativo devem ser assinados com o mesmo certificado.
Em outros casos, você não precisa ter essa configuração: o sistema de compilação simplesmente a assinará com um certificado integrado padrão, com base na variante de compilação, e normalmente é chamado de dev-keys .
test_suites: ["device-tests"],
A configuração test_suites torna o teste facilmente detectável pelo equipamento de teste da Trade Federation. Outras suítes podem ser adicionadas aqui, como CTS, para que este teste possa ser compartilhado.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configurações opcionais
As seguintes configurações opcionais fornecem explicação:
test_config: "path/to/hello_world_test.xml"
A configuração test_config instrui o sistema de compilação que seu alvo de teste precisa de uma configuração específica. Por padrão, um AndroidTest.xml próximo ao Android.bp está associado à configuração.
auto_gen_config: true
A configuração auto_gen_config indica se a configuração de teste deve ou não ser criada automaticamente. Se AndroidTest.xml não existir próximo a Android.bp , esse atributo não precisará ser definido como true explicitamente.
require_root: true
A configuração require_root instrui o sistema de compilação a adicionar RootTargetPreparer à configuração de teste gerada automaticamente. Isso garante que o teste seja executado com permissões de root.
test_min_api_level: 29
A configuração test_min_api_level instrui o sistema de compilação a adicionar MinApiLevelModuleController à configuração de teste gerada automaticamente. Quando Trade Federation executa a configuração de teste, o teste será ignorado se a propriedade do dispositivo ro.product.first_api_level < test_min_api_level .