Se você não tem experiência no desenvolvimento da plataforma Android, este exemplo completo de como adicionar 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 mais informações sobre a estrutura GTest para C++, consulte o site do projeto GTest (link em inglês) para acessar mais documentação.
Este guia usa o Hello World GTest como exemplo. Recomendamos ler o código para entender o que ele faz antes de continuar.
Decidir um local de origem
Normalmente, sua equipe já tem um padrão estabelecido de lugares para verificar no 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 <component source
root>, a maioria dos componentes tem pastas src e tests abaixo dele, além de alguns arquivos adicionais, como Android.mk (ou divididos em arquivos .bp adicionais).
Como você está adicionando um teste totalmente 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ê precisará criar um novo subdiretório em tests.
Para ilustrar, aqui está uma estrutura de diretório típica 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 cada arquivo em mais detalhes.
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>
Inclusão de arquivo de cabeçalho 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 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 mais informações sobre como escrever testes com o GTest, consulte a documentação dele.
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 framework 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 à classe de teste.
Criar e testar localmente
Para os casos de uso mais comuns, use Atest.
Para casos mais complexos que exigem personalização mais pesada, siga as instruções de instrumentação.