Google is committed to advancing racial equity for Black communities. See how.
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, pode achar este exemplo completo de adição de 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 seguinte teste para servir como um exemplo:

Hello World Native Test

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

Decidir sobre um local de origem

Normalmente, sua equipe já terá um padrão estabelecido de locais para fazer 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 tem um subdiretório dedicado que contém o código-fonte do componente.

Supondo que a localização raiz da fonte do componente seja <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 novo teste, 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 mais estruturas de diretório em tests devido à necessidade de empacotar diferentes suítes 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 no exemplo de mudança gerrit. As seções a seguir explicam com mais detalhes cada arquivo.

Código fonte

Veja o Teste Nativo Hello World para obter um exemplo.

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

#include <gtest/gtest.h>

Incluir arquivo de cabeçalho 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!");
}

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 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 gtest, consulte sua 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 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.

Construir e testar localmente

Para os casos de uso mais comuns, use Atest .

Para casos mais complexos que requerem personalização mais pesada, siga as instruções de instrumentação .