O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Configuração de construção simples

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. Android agora usa o sistema de compilação Soong para configuração de teste simples.

Soong usa Blueprint ou .bp arquivos, que são JSON-como descrições declarativas simples de módulos para construir. Este formato substitui o sistema baseado em Make usado em versões anteriores. Veja os arquivos de referência Soong no Painel de integração contínua para maiores detalhes.

Para acomodar o teste personalizado ou usar o Android Compatibility Test Suite (CTS), siga configuração de teste Complexo vez.

Exemplo

As entradas abaixo vêm de este exemplo de arquivo de configuração Blueprint: /platform_testing/tests/example/instrumentation/Android.bp

Um instantâneo está incluído aqui para sua conveniência:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Observe o android_test declaração no início indica este é um teste. Incluindo android_app seria inversamente indicar que este é sim um pacote de construção.

Definições

As seguintes configurações geram explicações:

    name: "HelloWorldTests",

O name definição é necessária quando o android_test tipo de módulo é especificado (no início do bloco). Dá um nome ao seu módulo, eo APK resultante será o mesmo nome e com um .apk sufixo, por exemplo, neste caso, resultando apk teste é nomeado como HelloWorldTests.apk . Além disso, este também define um nome de destino make para seu módulo, de modo que você pode usar make [options] <HelloWorldTests> para construir o seu módulo de teste e todas as suas dependências.

    static_libs: ["android-support-test"],

Os static_libs configuração instrui o sistema de compilação para incorporar o conteúdo dos módulos nomeados para o apk resultando de módulo atual. Isto significa que cada módulo chamado é esperada para produzir uma .jar ficheiro, e o seu conteúdo vai ser utilizado para a resolução de referências de caminho de classe durante o tempo de compilação, bem como incorporada no APK resultante.

Neste exemplo, coisas que geralmente podem ser úteis para testes:

A android-support-test é o pré-construídos para a Biblioteca de suporte Teste Android, que inclui o novo teste corredor AndroidJUnitRunner : um substituto para o agora obsoleto built-in InstrumentationTestRunner , com suporte para JUnit4 framework de testes. Leia mais em aplicativos de teste no Android .

Se você está construindo um novo módulo de instrumentação, você deve sempre começar com o android-support-test biblioteca como o corredor de teste. A árvore fonte plataforma também inclui outras estruturas de teste útil como ub-uiautomator , mockito-target , easymock e mais.

    certificate: "platform",

O certificate configuração instrui o sistema de construção a assinar o apk com o mesmo certificado como a plataforma central. Isso é necessário se o seu teste usar uma permissão protegida por assinatura ou API. Note-se que este é adequado para o teste contínuo plataforma, mas não deve ser utilizado 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ê está escrevendo uma instrumentação para o seu componente que vive fora do servidor do sistema, ou seja, é empacotado mais ou menos como um apk de aplicativo regular, exceto que é integrado à imagem do sistema e pode ser um aplicativo privilegiado, as chances são de que sua instrumentação irá ter como alvo o pacote do aplicativo (consulte a seção abaixo sobre o manifesto) do seu componente. Neste caso, seu makefile aplicativo pode ter seu próprio certificate configuração, 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 em tudo: o sistema de compilação será simplesmente assiná-lo com um padrão built-in de certificados, com base na variante de construção, e é normalmente chamado as dev-keys .

    test_suites: ["device-tests"],

O test_suites configuração faz com que o teste facilmente detectável pelo equipamento de teste Federação do Comércio. Outros conjuntos podem ser adicionados 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 obtêm explicações:

    test_config: "path/to/hello_world_test.xml"

O test_config configuração instrui o sistema de compilação seu alvo de teste precisa de uma configuração específica. Por padrão, um AndroidTest.xml ao lado do Android.bp está associado com a configuração.

    auto_gen_config: true

O auto_gen_config configuração indica se deve ou não criar a configuração de teste automaticamente. Se AndroidTest.xml não existe ao lado do Android.bp , este atributo não precisa ser definido como true explicitamente.

    require_root: true

O require_root configuração instrui o sistema de compilação para adicionar RootTargetPreparer à auto gerado configuração de teste. Isso garante que o teste seja executado com permissões de root.

    test_min_api_level: 29

O test_min_api_level configuração instrui o sistema de compilação para adicionar MinApiLevelModuleController à auto gerado configuração de teste. Quando Federação do Comércio funciona a configuração de teste, o teste será ignorada se a propriedade do dispositivo de ro.product.first_api_level < test_min_api_level .