Cada novo módulo de teste precisa ter um arquivo de configuração para direcionar o sistema de build com metadados do módulo, dependências de tempo de compilação e instruções de empacotamento. O Android agora usa o sistema de build Soong para uma configuração de teste mais simples.
O Soong usa arquivos Blueprint ou .bp, que são descrições declarativas simples de módulos a serem criados semelhantes a JSON. Esse formato substitui o sistema baseado em Make usado em versões anteriores. Consulte os arquivos de referência do Soong
no painel de integração contínua para mais detalhes.
Para acomodar testes personalizados ou usar o conjunto de testes de compatibilidade do Android (CTS), siga a configuração de teste complexa.
Exemplo
As entradas abaixo vêm deste arquivo de configuração do Blueprint de exemplo: /platform_testing/tests/example/instrumentation/Android.bp
Um snapshot é incluído aqui para sua conveniência:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
A declaração android_test no início indica que este é um teste.
A inclusão de android_app indicaria que este é um pacote de build.
Configurações
As configurações a seguir precisam de explicação:
name: "HelloWorldTests",
A configuração name é obrigatória quando o tipo de módulo android_test é especificado (no início do bloco). Ela dá um nome ao módulo, e o APK resultante terá o mesmo nome e um sufixo .apk. Por exemplo, nesse caso, o APK de teste resultante é chamado de HelloWorldTests.apk. Além disso, ele também
define um nome de destino de criação para o módulo, para que você possa usar make [options]
<HelloWorldTests> para criar o módulo de teste e todas as dependências dele.
static_libs: ["androidx.test.runner"],
A configuração static_libs instrui o sistema de build a incorporar o conteúdo dos módulos nomeados no APK resultante do módulo atual. Isso significa que cada módulo nomeado precisa produzir um arquivo .jar, e o conteúdo dele será usado para resolver referências de classpath durante o tempo de compilação, além de ser incorporado ao APK resultante.
O módulo androidx.test.runner é o pré-criado para a biblioteca do AndroidX Test Runner, que inclui o executor de testes AndroidJUnitRunner.
O AndroidJUnitRunner oferece suporte à estrutura de testes JUnit4 e substituiu o InstrumentationTestRunner no Android 10. Saiba mais
sobre como testar apps Android em Testar apps no Android.
Se você estiver criando um novo módulo de instrumentação, sempre comece com a biblioteca androidx.test.runner como 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 build a assinar o APK com o mesmo certificado da plataforma principal. Isso é necessário se o teste usar uma permissão ou API protegida por assinatura. Isso é adequado para testes contínuos da plataforma, mas não deve ser usado em módulos de teste do CTS. Este exemplo usa essa configuração de certificado apenas para fins de ilustração: o código de teste do exemplo não precisa que o APK de teste seja assinado com o certificado especial da plataforma.
Se você estiver escrevendo uma instrumentação para o componente que reside fora do servidor do sistema, ou seja, ele é empacotado mais ou menos como um APK de app normal, exceto que é criado na imagem do sistema e pode ser um app privilegiado, é provável que sua instrumentação seja direcionada ao pacote de apps (consulte a seção abaixo sobre o manifesto) do componente. Nesse caso, o arquivo make do aplicativo pode ter a própria configuração certificate, e o módulo de instrumentação precisa manter a mesma configuração. Isso ocorre porque, para direcionar a instrumentação no app em teste, o APK de teste e o APK do app precisam ser assinados com o mesmo certificado.
Em outros casos, não é necessário ter essa configuração: o sistema de build simplesmente a assinará com um certificado integrado padrão, com base na variante de build, e normalmente é chamado de dev-keys.
test_suites: ["device-tests"],
A configuração test_suites facilita a descoberta do teste pelo harness de teste da Trade Federation. Outros conjuntos podem ser adicionados aqui, como o CTS, para que esse teste possa ser compartilhado.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configurações opcionais
As configurações opcionais a seguir precisam de explicação:
test_config: "path/to/hello_world_test.xml"
A configuração test_config instrui o sistema de build de que o destino do teste precisa de uma configuração específica. Por padrão, um AndroidTest.xml ao lado do Android.bp está associado à configuração.
auto_gen_config: true
A configuração auto_gen_config indica se a configuração de teste será criada automaticamente ou não. Se AndroidTest.xml não existir ao lado do Android.bp, esse atributo não precisará ser definido como verdadeiro explicitamente.
require_root: true
A configuração require_root instrui o sistema de build a adicionar RootTargetPreparer à configuração de teste gerada automaticamente. Isso garante que o teste seja executado com permissões de raiz.
test_min_api_level: 29
A configuração test_min_api_level instrui o sistema de build a adicionar MinApiLevelModuleController à configuração de teste gerada automaticamente. Quando a Trade Federation executa a configuração de teste, o teste será ignorado se a propriedade do dispositivo de ro.product.first_api_level < test_min_api_level.