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 descrições declarativas
simples de módulos a serem criados, semelhantes a JSON. 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 mais detalhes.
Para acomodar testes personalizados ou usar o 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 configurações a seguir precisam de explicação:
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 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, 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, sempre comece com
a biblioteca androidx.test.runner como o executor de teste. 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. 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 o componente que fica fora do
servidor do sistema, ou seja, ele é empacotado mais ou menos como um APK de app normal,
exceto que ele é integrado à imagem do sistema e pode ser um app privilegiado, é provável
que a instrumentação seja direcionada ao pacote do app (consulte a seção abaixo
sobre o manifesto) do 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, para segmentar
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 a assina com um certificado integrado padrão, com base na variante
do build, e normalmente é chamado 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 CTS, para que esse
teste seja 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 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 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.