Se você não tem experiência com desenvolvimento na Plataforma Android, talvez considere o exemplo de adição de um novo binário GTest, também chamado de teste) do zero, úteis para demonstrar o fluxo de trabalho típico envolvido. Para mais informações sobre a estrutura do GTest para C++, consulte o projeto GTest site para ver a documentação adicional.
Este guia usa o Hello World GTest como exemplo. Recomendamos a leitura do código para uma compreensão aproximada antes de continuar.
Escolher um local de origem
Normalmente, sua equipe já terá um padrão estabelecido de lugares para verificar no código e locais para adicionar testes. A maioria das equipes tem um único repositório Git ou compartilhar um com outras equipes, mas ter 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 novo teste, provavelmente será necessário criar o
tests ao lado do componente src e o preencha com conteúdo.
Em alguns casos, sua equipe pode ter mais estruturas de diretórios 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
\-- ...
e este é um esboço de diretório comum para componentes com várias fontes de teste diretórios:
\
<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ê preencherá o diretório tests ou
o subdiretório recém-criado com arquivos semelhantes aos que estão no native
na alteração do Gerrit de amostra. As seções abaixo explicarão em
mais detalhes de cada arquivo.
Código-fonte
Consulte o Hello World GTest. como exemplo.
O código-fonte desse exemplo está anotado aqui:
#include <gtest/gtest.h>
O arquivo de cabeçalho incluído para o GTest. A dependência de arquivos incluídos é automaticamente
resolvido usando BUILD_NATIVE_TEST no makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Os GTests são criados usando a macro TEST: o primeiro parâmetro é o caso de teste.
e o segundo é o nome do teste. Junto com o nome binário do teste, eles formam o
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 programar 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 de módulos, dependências de tempo de compilação e empacotamento instruções. Na maioria dos casos, a opção de arquivo de blueprint baseada em Soong é suficiente. Consulte Configuração de teste simples para ver detalhes.
Arquivo de configuração complexo
Para usar a Trade Federation, crie uma configuração de teste para o arcabouço de testes do Android, a Trade Federation.
A configuração de teste pode especificar opções especiais de configuração do dispositivo e para fornecer a 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 complexa, siga as instruções de instrumentação.