O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Adicionando novos GoogleTests (GTests)

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Se você é novo no desenvolvimento da plataforma Android, este exemplo completo de adição de 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 obter informações adicionais sobre a estrutura GTest para C++, consulte o site do projeto GTest para obter documentação adicional.

Este guia usa o Hello World GTest como exemplo. Recomendamos a leitura do código para obter uma compreensão aproximada antes de continuar.

Decidindo sobre um local de origem

Normalmente, sua equipe já terá um padrão estabelecido de locais para fazer check-in de 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.

Assumindo que o local raiz da origem do componente está em <component source root> , a maioria dos componentes tem as pastas src e tests sob ele 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 seu 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. 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 na alteração do gerrit de amostra. As seções abaixo explicarão com mais detalhes cada arquivo.

Código fonte

Consulte o Hello World GTest para obter um exemplo.

O código-fonte para esse exemplo está anotado aqui:

#include <gtest/gtest.h>

Arquivo de cabeçalho incluído 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!");
}

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 obter 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 deve ter um arquivo de configuração para direcionar o sistema de compilação com metadados de 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.

Crie e teste localmente

Para os casos de uso mais comuns, empregue Atest .

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