Se você é iniciante no desenvolvimento da plataforma Android, este exemplo completo de como adicionar um novo binário do GTest (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 para mais documentação.
Este guia usa o GTest Hello World como exemplo. Recomendamos ler o código para ter uma compreensão geral dele antes de continuar.
Decidir um local de origem
Normalmente, sua equipe já tem um padrão estabelecido de lugares para fazer check-in de código e lugares para adicionar testes. A maioria das equipes tem um único repositório Git ou compartilha um com outras equipes, mas tem um subdiretório dedicado que contém o código-fonte do componente.
Supondo que o local raiz da origem do componente seja 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 arquivos .bp
adicionais).
Como você está adicionando um novo teste, provavelmente precisará criar o diretório tests ao lado do src do componente 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ê precisará criar um novo subdiretório em tests.
Para ilustrar, confira 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
\-- ...
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
| \-- ...
\-- ...
Independente da estrutura, você vai acabar preenchendo o diretório tests ou o subdiretório recém-criado com arquivos semelhantes aos do diretório native na mudança de exemplo do Gerrit. As seções abaixo explicam mais detalhes de cada arquivo.
Código-fonte
Consulte o GTest Hello World para ver um exemplo.
O código-fonte desse exemplo está anotado aqui:
#include <gtest/gtest.h>
Incluir arquivo principal 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!");
}
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 do 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 Blueprint baseada em Soong é suficiente. Consulte Configuração de teste simples para mais detalhes.
Arquivo de configuração complexo
Para usar o Trade Federation, escreva um arquivo de configuração de teste para o harness de teste do Android, o 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 Atest.
Para casos mais complexos que exigem personalização mais pesada, siga as instruções de instrumentação.