Se você é novo no desenvolvimento da plataforma Android, este exemplo completo de adição de um novo binário GTest (também chamado de teste "nativo") do zero pode ser ú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 obter uma compreensão aproximada antes de continuar.
Decidindo sobre um local de origem
Normalmente, sua equipe já terá um padrão estabelecido de locais para fazer check-in de 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.
Assumindo que o local raiz da origem do componente está em <component source root> , a maioria dos componentes tem as pastas src e tests sob ele 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 de tests próximo ao seu 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. E neste caso, você 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 de 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 de tests ou o subdiretório recém-criado com arquivos semelhantes ao que está 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 obter um exemplo.
O código-fonte para esse exemplo está anotado aqui:
#include <gtest/gtest.h>
Arquivo de cabeçalho incluído para GTest. A dependência do arquivo de inclusão é 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 do 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 o 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 compilação com metadados de 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, empregue Atest .
Para casos mais complexos que exigem personalização mais pesada, siga as instruções de instrumentação .