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

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 estão familiarizados com o quadro gtest para C ++, consulte o site do projeto gtest para documentação adicional.

Este guia usa o seguinte teste para servir de 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.

Assumindo o local raiz para a sua fonte componente está em <component source root> , a maioria dos componentes têm src e tests pastas abaixo dela, e alguns arquivos adicionais, tais como Android.mk (ou divididos em adicionais .bp arquivos).

Desde que você está adicionando um teste novo, você provavelmente vai precisar para criar a tests diretório ao lado de seu componente src , e preenchê-lo com conteúdo.

Em alguns casos, sua equipe pode ter outras estruturas de diretórios sob tests , devido à necessidade de embalar diferentes suites de testes em binários individuais. E, neste caso, você precisa criar um novo diretório sub sob tests .

Para ilustrar, aqui está um esboço diretório típico para componentes com um único tests de pasta:

\
 <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ê vai acabar de preencher a tests diretório ou o diretório sub recém-criado com arquivos semelhantes ao que está na native diretório na mudança gerrit amostra. As seções abaixo explicarão em mais detalhes de cada arquivo.

Código fonte

Veja o teste Olá Mundo Native para um exemplo.

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

#include <gtest/gtest.h>

Incluir arquivo de cabeçalho para gtest. Note que o incluem dependência de arquivo é automaticamente resolvido usando BUILD_NATIVE_TEST no makefile

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

gtests são escritos usando TEST macro: o primeiro parâmetro é o nome do caso de teste, eo segundo é o nome de teste; junto 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 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. Veja simples configuração de teste para mais detalhes.

Arquivo de configuração complexo

Para usar Federação do Comércio em vez disso, escrever um arquivo de configuração de teste para equipamento de teste do Android, Federação do Comércio .

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 a maioria dos casos de uso comum, empregar Atest .

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