Se você é iniciante no desenvolvimento de plataformas Android, este exemplo completo de como adicionar um binário GTest totalmente novo (também chamado de teste "nativo") do zero pode ser útil para demonstrar o fluxo de trabalho típico envolvido. Para mais informações sobre o framework GTest para C++, consulte o site do projeto GTest (em inglês) para conferir mais documentação.
Este guia usa o Hello World GTest como exemplo. Recomendamos ler o código para entender melhor antes de continuar.
Decidir um local de origem
Normalmente, sua equipe já tem um padrão estabelecido de lugares para verificar o código e adicionar testes. A maioria das equipes tem um único repositório do Git ou compartilham um com outras equipes, mas têm um subdiretório dedicado que contém o código-fonte do componente.
Supondo que o local raiz da origem do componente esteja em <component source
root>, a maioria dos componentes tem pastas src e tests abaixo dele e alguns
arquivos adicionais, como Android.mk (ou divididos em outros arquivos
.bp).
Como você está adicionando um teste novo, provavelmente vai precisar criar o
diretório tests ao lado do componente src e preenchê-lo com conteúdo.
Em alguns casos, sua equipe pode ter outras estruturas de diretório em tests
devido à necessidade de empacotar diferentes conjuntos de testes em binários individuais.
Nesse caso, você vai precisar criar um novo subdiretório em tests.
Para ilustrar, aqui está um esboço de diretório típico para componentes com uma única
pasta tests:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- src (test source)
\-- foo_test.cpp
\-- ...
Confira um exemplo de diretório para componentes com vários diretórios de origem de teste:
\
<component source root>
\-- Android.bp (component makefile)
\-- AndroidTest.xml (test config file)
\-- src (component source)
| \-- foo.cpp
| \-- ...
\-- tests (test source root)
\-- Android.bp (test makefile)
\-- testFoo (sub test source root)
| \-- Android.bp (sub test makefile)
| \-- src (sub test source)
| \-- test_foo.cpp
| \-- ...
\-- testBar
| \-- Android.bp
| \-- src
| \-- test_bar.cpp
| \-- ...
\-- ...
Independentemente da estrutura, você vai preencher o diretório tests ou
o subdiretório recém-criado com arquivos semelhantes aos que estão no diretório native
na mudança de exemplo do gerrit. As seções abaixo explicam em
mais detalhes cada arquivo.
Código-fonte
Consulte o Hello World GTest para conferir um exemplo.
O código-fonte desse exemplo está anotado aqui:
#include <gtest/gtest.h>
Incluir arquivo de cabeçalho para GTest. A dependência de arquivo de inclusão é resolvida automaticamente
usando BUILD_NATIVE_TEST no makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Os GTests são escritos usando a macro TEST: o primeiro parâmetro é o nome do caso de teste
e o segundo é o nome do teste. Junto com o nome binário de teste, eles formam a
seguinte hierarquia no painel de resultados:
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
Para mais informações sobre como escrever testes com o GTest, consulte a documentação do GTest.
Arquivo de configuração 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. Na maioria dos casos, a opção de arquivo de blueprint baseada em Soong é suficiente. Consulte Configuração de teste simples para mais detalhes.
Arquivo de configuração complexo
Para usar a Trade Federation, escreva um arquivo de configuração de teste para o harness de teste do Android, Trade Federation.
A configuração de teste pode especificar opções especiais de configuração do dispositivo e argumentos padrão para fornecer a classe de teste.
Criar e testar localmente
Para os casos de uso mais comuns, use o Atestado.
Para casos mais complexos que exigem uma personalização mais pesada, siga as instruções de instrumentação.