Configuração de build simples

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 semelhantes a JSON de módulos a serem criados. 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 conferir todos os detalhes.

Para acomodar testes personalizados ou usar o Conjunto de teste de compatibilidade (CTS) do Android, siga 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

Confira um snapshot para facilitar:

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 que este é um pacote de build.

Configurações

Confira a explicação das seguintes configurações:

    name: "HelloWorldTests",

A configuração name é obrigató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 um sufixo .apk. Por exemplo, neste caso, o APK de teste resultante é chamado de HelloWorldTests.apk. Além disso, isso também define um nome de destino de make para seu módulo. Assim, você pode 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 deve 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 é compatível com o framework de teste 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 seu executor de testes. A árvore de origem da plataforma também inclui outros frameworks 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 usa uma permissão ou API protegida por assinatura. Isso é adequado para testes contínuos de 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 seu componente que fica fora do servidor do sistema, ou seja, ele é empacotado mais ou menos como um APK de app comum, exceto que ele é integrado à imagem do sistema e pode ser um app privilegiado, é provável que sua instrumentação tenha como destino o pacote do app (consulte abaixo a seção sobre manifesto) do seu componente. Nesse caso, o makefile do aplicativo pode ter a própria configuração certificate, e o módulo de instrumentação precisa manter a mesma configuração. Isso acontece porque, para direcionar sua 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 assina com um certificado padrão integrado, com base na variante de build, e geralmente é chamado de dev-keys.

    test_suites: ["device-tests"],

A configuração test_suites facilita a descoberta do teste pelo arnês de teste da Trade Federation. Outros pacotes 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 seguintes configurações opcionais 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 é associado à configuração.

    auto_gen_config: true

A configuração auto_gen_config indica se a configuração de teste será criada automaticamente. Se AndroidTest.xml não existir ao lado de Android.bp, esse atributo não precisará ser definido como "true" 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 é ignorado se a propriedade do dispositivo de ro.product.first_api_level < test_min_api_level.