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 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 conferir todos os detalhes.
Para acomodar testes personalizados ou usar o Conjunto de teste de compatibilidade (CTS) do Android, siga a Configuração de teste complexo.
Exemplo
As entradas abaixo são do arquivo de configuração de exemplo do Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Um snapshot 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"],
}
A declaração android_test no início indica que este é um teste.
A inclusão de android_app indicaria, por outro lado, que se trata de um pacote de
build.
Configurações
As configurações a seguir têm 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 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 o módulo, para que você possa 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 precisa produzir um arquivo .jar, e o conteúdo dele será
usado para resolver referências de classpath durante a compilação, além de
ser incorporado ao APK resultante.
O módulo androidx.test.runner é o pré-criado para a biblioteca AndroidX Test Runner, que inclui o executor de teste AndroidJUnitRunner.
O AndroidJUnitRunner oferece suporte ao framework de teste JUnit4 e substituiu
InstrumentationTestRunner no Android 10. Leia 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 executor de teste. A árvore de origem da plataforma
também inclui outros frameworks de teste úteis, como ub-uiautomator,
mockito-target, easymock e outros.
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 usar 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 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, 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 ocorre porque, para segmentar a
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 compilação a assinará com um certificado integrado padrão, baseado na variante de build, e normalmente é chamada de dev-keys.
test_suites: ["device-tests"],
A configuração test_suites facilita a descoberta do teste pelo harness de teste da Trade
Federation. Outros pacotes podem ser adicionados aqui, como o CTS, para que este
teste possa ser compartilhado.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Configurações opcionais
As configurações opcionais a seguir são explicadas:
test_config: "path/to/hello_world_test.xml"
A configuração test_config instrui o sistema de build que o destino de 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 do teste será criada automaticamente ou não. 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 o 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 do teste, o teste é ignorado se a propriedade do dispositivo
de ro.product.first_api_level for menor que test_min_api_level.