Configuração do 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 simplificar configuração do teste.

O Soong usa arquivos Blueprint ou .bp, que são declarativos simples do tipo JSON descrições dos módulos a serem criados. Este formato substitui o sistema baseado em Make usadas 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 teste de compatibilidade (CTS) do Android, siga Configuração de teste complexa como alternativa.

Exemplo

As entradas abaixo provêm deste exemplo de arquivo de configuração Blueprint: /platform_testing/tests/example/instrumentation/Android.bp (link em inglês)

Um snapshot 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"],
}

A declaração android_test no início indica que é um teste. Incluir android_app indica, por outro lado, que se trata de um build. .

Configurações

As seguintes configurações são explicadas:

    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 módulo e o resultado O APK terá o mesmo nome e terá um sufixo .apk, por exemplo: nesse caso, O APK de teste resultante é nomeado como HelloWorldTests.apk. Além disso, ela também define um nome de destino para o módulo. Assim, você pode usar o 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 produz um arquivo .jar, e o conteúdo dele será usada para resolver referências de caminho de classe durante a compilação, bem como incorporada no apk resultante.

O módulo androidx.test.runner é pré-criado para o AndroidX Test Runner Biblioteca, que inclui o executor de testes AndroidJUnitRunner. AndroidJUnitRunner oferece suporte ao framework de testes JUnit4 e substituiu InstrumentationTestRunner no Android 10. Ler mais sobre como testar apps Android em Testar apps no Android.

Se você estiver criando um novo módulo de instrumentação, comece sempre com a biblioteca androidx.test.runner como executor de testes. A árvore de origem da plataforma também inclui outros frameworks de teste úteis, como ub-uiautomator, mockito-target, easymock e mais.

    certificate: "platform",

A configuração certificate instrui o sistema de compilação a assinar o APK com a mesma como plataforma principal. É necessário se o teste usa uma assinatura uma permissão ou API protegida. Isso é adequado para casos de uso contínuo mas não podem ser usados em módulos de teste CTS. Esse exemplo usa esta configuração de certificado apenas para fins ilustrativos: o código de teste do exemplo não precisa que o APK de teste seja assinado com a certificado especial de plataforma.

Se você estiver escrevendo uma instrumentação para seu componente que esteja fora servidor do sistema, isto é, vem mais ou menos parecido com um apk de app normal, exceto por ser integrado à imagem do sistema e pode ser um aplicativo privilegiado, as chances é que sua instrumentação será direcionada ao pacote do app (veja abaixo seção sobre manifesto) do seu componente. Nesse caso, seu aplicativo O makefile pode ter a própria configuração certificate, e sua instrumentação deve manter a mesma configuração. Isso acontece porque segmentar seus 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, você não precisa ter essa configuração: o sistema de build o assinará com um certificado padrão integrado, com base no variante e normalmente é chamada de dev-keys.

    test_suites: ["device-tests"],

A configuração test_suites facilita a descoberta do teste pelo Trade. Arcabouço de testes de federação. Outros pacotes podem ser adicionados aqui, como o CTS, para que esta teste poderá ser compartilhado.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Configurações opcionais

As seguintes configurações opcionais são explicadas:

    test_config: "path/to/hello_world_test.xml"

A configuração test_config instrui o sistema de build que seu destino de teste precisa configuração específica. Por padrão, um AndroidTest.xml ao lado do Android.bp é associados à configuração.

    auto_gen_config: true

A configuração auto_gen_config indica se a configuração de teste será criada ou não. automaticamente. Se AndroidTest.xml não existir ao lado de Android.bp, esse não precisa ser definido explicitamente como verdadeiro.

    require_root: true

A configuração require_root instrui o sistema de build a adicionar o RootTargetPreparer à configuração de teste gerada automaticamente. Isso garante que o teste seja executado com acesso root permissões.

    test_min_api_level: 29

A configuração test_min_api_level instrui o sistema de build a adicionar MinApiLevelModuleController para a configuração de teste gerada automaticamente. Quando negociar A federação 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.