Se você é novo no desenvolvimento da plataforma Android, pode achar este exemplo completo de adição de um novo binário GTest (às vezes também chamado de teste "nativo") do zero, útil para demonstrar o fluxo de trabalho típico envolvido. Para obter informações adicionais sobre a estrutura GTest para C++, consulte o site do projeto GTest para obter documentação adicional.
Este guia usa o Hello World GTest como exemplo. Recomendamos a leitura do código para entendê-lo aproximadamente antes de continuar.
Decida um local de origem
Normalmente, sua equipe já terá um padrão estabelecido de locais para fazer check-in do código e locais para adicionar testes. A maioria das equipes possui um único repositório git ou compartilha um com outras equipes, mas possui um subdiretório dedicado que contém o código-fonte do componente.
Supondo que o local raiz da origem do seu componente esteja em <component source root> , a maioria dos componentes possui pastas src e tests e alguns arquivos adicionais, como Android.mk (ou divididos em arquivos .bp adicionais).
Como você está adicionando um novo teste, provavelmente precisará criar o diretório tests próximo ao seu componente src e preenchê-lo com conteúdo.
Em alguns casos, sua equipe pode ter estruturas de diretório adicionais em tests devido à necessidade de empacotar diferentes conjuntos de testes em binários individuais. E neste caso, você precisará criar um novo subdiretório em tests .
Para ilustrar, aqui está um esboço típico de diretório 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
\-- ...
e aqui está um esboço de diretório típico 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ê acabará preenchendo o diretório tests ou o subdiretório recém-criado com arquivos semelhantes aos que estão no diretório native na alteração do gerrit de amostra. As seções abaixo explicarão com mais detalhes cada arquivo.
Código fonte
Consulte o Hello World GTest para ver um exemplo.
O código-fonte desse exemplo está anotado aqui:
#include <gtest/gtest.h>
Arquivo de cabeçalho incluído para GTest. A dependência do arquivo incluído é resolvida automaticamente usando BUILD_NATIVE_TEST no makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
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 obter mais informações sobre como escrever testes com GTest, consulte a documentação do GTest
Arquivo de configuraçã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. Na maioria dos casos, a opção de arquivo Blueprint baseada em Soong é suficiente. Consulte Configuração de teste simples para obter detalhes.
Arquivo de configuração complexo
Para usar o Trade Federation, escreva um arquivo de configuração de teste para o equipamento de teste do Android, Trade Federation .
A configuração de teste pode especificar opções especiais de configuração de dispositivo e argumentos padrão para fornecer a classe de teste.
Crie e teste localmente
Para os casos de uso mais comuns, utilize Atest .
Para casos mais complexos que exigem customização mais pesada, siga as instruções de instrumentação .