O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Adicionando um novo exemplo de teste nativo

Se você é novo no desenvolvimento da plataforma Android, poderá encontrar este exemplo completo de adicionar um novo teste nativo do zero útil para demonstrar o fluxo de trabalho típico envolvido. Além disso, se você também não estiver familiarizado com a estrutura gtest para C ++, consulte o site do projeto gtest para obter documentação adicional.

Este guia usa o teste a seguir para servir como uma amostra:

Olá teste nativo do mundo

É recomendável navegar pelo código primeiro para obter uma impressão aproximada antes de continuar.

Decidindo sobre um local de origem

Normalmente, sua equipe já terá um padrão estabelecido de locais para o 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 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 teste totalmente novo, provavelmente precisará criar o diretório de tests próximo ao src componente e preenchê-lo com conteúdo.

Em alguns casos, sua equipe pode ter estruturas de diretórios adicionais sob tests devido à necessidade de empacotar diferentes conjuntos de testes em binários individuais. E, nesse caso, você precisará criar um novo subdiretório sob tests .

Para ilustrar, aqui está um esboço típico de diretório 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 típico de diretório 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 de amostra de gerrit. As seções abaixo explicam mais detalhes de cada arquivo.

Código fonte

Veja o Hello World Native Test para um exemplo.

O código-fonte anotado está listado abaixo:

 #include <gtest/gtest.h>
 

O arquivo de cabeçalho inclui para gtest. Observe que 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 gravados usando a macro TEST : o primeiro parâmetro é o nome do caso de teste e o segundo é o nome do teste; juntamente com o nome binário de teste, eles formam a hierarquia abaixo quando visualizados 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:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

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 em 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 simples de teste para obter detalhes.

Arquivo de configuração complexo

Para usar a Trade Federation, escreva um arquivo de configuração de teste para o chicote de teste do Android, 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.

Construa e teste 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 da instrumentação .