Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados do 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 do 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 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 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"],
}
Observe que a declaração android_test no início indica que este é um teste. Inversamente, incluir android_app indicaria que este é um pacote de compilação.
Configurações
As configurações a seguir fornecem explicações:
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 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 make target 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: ["androidx.test.runner"],
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.
O módulo androidx.test.runner é o pré-criado para a AndroidX Test Runner Library, que inclui o executor de teste AndroidJUnitRunner . AndroidJUnitRunner oferece suporte à estrutura de teste JUnit4 e substituiu InstrumentationTestRunner no Android 10. Leia mais sobre como testar aplicativos Android em Testar aplicativos no Android .
Se você estiver criando um novo módulo de instrumentação, sempre deve começar com a biblioteca androidx.test.runner como seu executor de teste. 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 compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso é necessário se seu teste usar uma API ou permissão protegida por assinatura. Observe que isso é adequado para teste contínuo 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ê está escrevendo uma instrumentação para o seu componente que reside fora do servidor do sistema, ou seja, é empacotado mais ou menos como um apk de aplicativo normal, exceto que está integrado à 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 o manifesto) do seu componente. Nesse caso, seu makefile de aplicativo pode ter sua própria configuração 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 assiná-lo com um certificado integrado 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 equipamento de teste da Trade Federation. 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 fornecem 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 está associado à configuração.
auto_gen_config: true
A configuração auto_gen_config indica se deve ou não criar a configuração de teste 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 .
Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados do 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 do 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 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 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"],
}
Observe que a declaração android_test no início indica que este é um teste. Inversamente, incluir android_app indicaria que este é um pacote de compilação.
Configurações
As configurações a seguir fornecem explicações:
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 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 make target 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: ["androidx.test.runner"],
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.
O módulo androidx.test.runner é o pré-criado para a AndroidX Test Runner Library, que inclui o executor de teste AndroidJUnitRunner . AndroidJUnitRunner oferece suporte à estrutura de teste JUnit4 e substituiu InstrumentationTestRunner no Android 10. Leia mais sobre como testar aplicativos Android em Testar aplicativos no Android .
Se você estiver criando um novo módulo de instrumentação, sempre deve começar com a biblioteca androidx.test.runner como seu executor de teste. 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 compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso é necessário se seu teste usar uma API ou permissão protegida por assinatura. Observe que isso é adequado para teste contínuo 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ê está escrevendo uma instrumentação para o seu componente que reside fora do servidor do sistema, ou seja, é empacotado mais ou menos como um apk de aplicativo normal, exceto que está integrado à 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 o manifesto) do seu componente. Nesse caso, seu makefile de aplicativo pode ter sua própria configuração 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 assiná-lo com um certificado integrado 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 equipamento de teste da Trade Federation. 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 fornecem 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 está associado à configuração.
auto_gen_config: true
A configuração auto_gen_config indica se deve ou não criar a configuração de teste 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 .
Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados do 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 do 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 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 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"],
}
Observe que a declaração android_test no início indica que este é um teste. Inversamente, incluir android_app indicaria que este é um pacote de compilação.
Configurações
As configurações a seguir fornecem explicações:
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 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 make target 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: ["androidx.test.runner"],
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.
O módulo androidx.test.runner é o pré-criado para a AndroidX Test Runner Library, que inclui o executor de testes AndroidJUnitRunner . AndroidJUnitRunner oferece suporte à estrutura de teste JUnit4 e substituiu InstrumentationTestRunner no Android 10. Leia mais sobre como testar aplicativos Android em Testar aplicativos no Android .
Se você estiver criando um novo módulo de instrumentação, sempre deve começar com a biblioteca androidx.test.runner como seu executor de teste. 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 compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso é necessário se seu teste usar uma API ou permissão protegida por assinatura. Observe que isso é adequado para teste contínuo 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ê está escrevendo uma instrumentação para o seu componente que reside fora do servidor do sistema, ou seja, é empacotado mais ou menos como um apk de aplicativo normal, exceto que está integrado à 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 o manifesto) do seu componente. Nesse caso, seu makefile de aplicativo pode ter sua própria configuração 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 assiná-lo com um certificado integrado 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 equipamento de teste da Trade Federation. 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 fornecem 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 está associado à configuração.
auto_gen_config: true
A configuração auto_gen_config indica se deve ou não criar a configuração de teste 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 .