Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados de 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 em versões anteriores. Consulte os arquivos de referência 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: ["android-support-test"],
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 reúnem explicações:
name: "HelloWorldTests",
A configuração de 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 será nomeado da mesma forma 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: ["android-support-test"],
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 cada módulo nomeado deve produzir 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.
Neste exemplo, coisas que podem ser geralmente úteis para testes:
O android-support-test é o pré-compilado para a Android Test Support Library, que inclui o novo executor de teste AndroidJUnitRunner : um substituto para o InstrumentationTestRunner integrado, agora obsoleto, com suporte para a estrutura de teste JUnit4. Leia mais em Testar aplicativos no Android .
Se você estiver criando um novo módulo de instrumentação, deve sempre começar com a biblioteca android-support-test 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 do certificate instrui o sistema de compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso é necessário se seu teste usar uma permissão ou API 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 essa 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 o seu componente que vive fora do servidor do sistema, ou seja, ele é empacotado 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 estar direcionando o pacote do aplicativo (veja a seção abaixo sobre manifesto) do seu componente. Nesse caso, o makefile do seu aplicativo pode ter sua própria configuração de certificate e seu módulo de instrumentação deve manter a mesma configuração. Isso ocorre porque para direcionar sua instrumentação no 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 assinará com um certificado interno 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 conjunto de testes da Federação de Comércio. 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 reúnem explicações:
test_config: "path/to/hello_world_test.xml"
A configuração test_config instrui o sistema de compilação que seu destino de teste precisa de uma configuração específica. Por padrão, um AndroidTest.xml próximo ao Android.bp é 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 ao lado de Android.bp , esse atributo não precisa 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 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 .