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

Mapeamento de Teste

Esta é uma breve introdução ao Mapeamento de Teste e uma explicação de como começar a configurar testes facilmente no Android Open Source Project (AOSP).

O que é mapeamento de teste?

Test Mapping é uma abordagem baseada em Gerrit que permite aos desenvolvedores criar regras de teste pré e pós-envio diretamente na árvore de origem do Android e deixar as decisões de ramificações e dispositivos a serem testadas para a própria infraestrutura de teste. As definições de mapeamento de teste são arquivos JSON denominados TEST_MAPPING que podem ser colocados em qualquer diretório de origem.

Atest pode usar os arquivos TEST_MAPPING para executar testes presubmit nos diretórios associados. Com o mapeamento de teste, você pode adicionar o mesmo conjunto de testes para pré-enviar verificações com uma simples mudança dentro da árvore de origem do Android.

Veja estes exemplos:

Adicionar pré-enviar testes a TEST_MAPPING para services.core

Adicionar testes de pré-envio a TEST_MAPPING para ferramentas / dexter usando importações

Teste de mapeamento depende da Federação do Comércio (TF) Harness de teste para execução testes e resultados de relatórios.

Definindo grupos de teste

Grupos teste de mapeamento testa através de um grupo de teste. O nome de um grupo de teste pode ser qualquer string. Por exemplo, pode ser presubmit para um grupo de testes para correr ao validar alterações. E testes postsubmit pode ser usado para validar as compilações após as alterações são mescladas.

Empacotando regras de script de compilação

Para que a Federação do Comércio Harness de teste para executar módulos de teste de teste de mapeamento para uma determinada construção, estes módulos deve ter test_suite conjunto para Soong ou LOCAL_COMPATIBILITY_SUITE conjunto de Make a uma destas duas suites:

  • gerais-testes - testes que não dependem de recursos específicos do dispositivo. A maioria dos testes deve estar no conjunto de testes gerais, pois eles podem ser construídos no destino test_suites que inclui os binários (para testes nativos) em todos os ABIs suportados (32 vs 64).
  • dispositivo-testes - testes dependem de características específicas do dispositivo, executável somente em determinados alvos dispositivo, ou só pode ser construída apenas em determinadas metas de dispositivo. Isso é verdade quer o teste seja um teste nativo ou um teste JUnit.

Exemplos:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurando testes para serem executados em um conjunto de testes

Para que um teste seja executado dentro de um conjunto de testes, o teste:

  • não deve ter nenhum provedor de compilação.
  • deve limpar depois de concluído, por exemplo, excluindo quaisquer arquivos temporários gerados durante o teste.
  • altere as configurações do sistema para o valor padrão ou original.

  • não deve assumir um dispositivo em um determinado estado, por exemplo, pronto para root. A maioria dos testes não requer privilégio de root para ser executado. Se um teste deve exigir root, ele deve especificar isso com um RootTargetPreparer, por exemplo:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Criação de arquivos de mapeamento de teste

Para o diretório que requer cobertura de teste, basta adicionar um arquivo JSON TEST_MAPPING semelhante ao exemplo abaixo. Essas regras garantirão que os testes sejam executados em verificações de pré-envio quando qualquer arquivo for tocado naquele diretório ou em qualquer um de seus subdiretórios.

Seguindo um exemplo

Aqui está um exemplo TEST_MAPPING arquivo (que é em formato JSON, mas com comentários suportado):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Atributos de configuração

No exemplo acima, presubmit e postsubmit são os nomes de cada grupo de teste. Consulte Definindo grupos de teste para obter mais informações sobre grupos de teste.

O nome do módulo de teste ou nome Federação do Comércio de teste de integração (caminho de recurso para o arquivo XML de teste, por exemplo, uiautomator / uiautomator-demo ) pode ser definida no valor do name atributo. Observe o campo de nome não pode usar a classe name ou método de teste name . Para limitar os testes a serem executados, você pode usar opções como include-filter aqui. Veja ( incluem-filtro uso de amostra ).

A configuração de host de um teste indica se o teste é um teste sem dispositivos rodando em host ou não. O valor padrão é falso, ou seja, o teste requer um dispositivo para executar. Os tipos de teste são suportados HostGTest para testes nativas e HostTest para testes JUnit.

O atributo file_patterns permite que você defina uma lista de strings regex para combinar o caminho relativo de qualquer arquivo de código fonte (em relação ao diretório contendo o arquivo TEST_MAPPING). No exemplo acima, teste CtsWindowManagerDeviceTestCases será executado em presubmit somente quando nenhum começa arquivo java com janela ou Atividade, que existe no mesmo diretório do arquivo TEST_MAPPING ou qualquer de seus subdiretórios, é alterado. As barras invertidas \ precisam de escape, pois estão em um arquivo JSON.

O atributo importações permite incluir testes em outros arquivos TEST_MAPPING sem copiar o conteúdo. Observe que os arquivos TEST_MAPPING nos diretórios pais do caminho importado também serão incluídos. O mapeamento de teste permite importações aninhadas; isso significa que dois arquivos TEST_MAPPING podem importar um ao outro e o mapeamento de teste é capaz de mesclar adequadamente os testes incluídos.

O atributo de opções contém opções adicionais de linha de comando TradeFed.

Para obter uma lista completa das opções disponíveis para um determinado teste, execute:

tradefed.sh run commandAndExit [test_module] --help

Consulte TradeFed Opção Manipulação para mais detalhes sobre como opções de trabalho.

Executando testes com Atest

Para executar as regras de teste de pré-envio localmente:

  1. Vá para o diretório que contém o arquivo TEST_MAPPING.
  2. Execute o comando:
atest

Todos os testes de pré-envio configurados nos arquivos TEST_MAPPING do diretório atual e seus diretórios pais são executados. O Atest localizará e executará dois testes de pré-envio (A e B).

Esta é a maneira mais simples de executar testes de pré-envio em arquivos TEST_MAPPING no diretório de trabalho atual (CWD) e nos diretórios pais. Atest irá localizar e usar o arquivo TEST_MAPPING no CWD e todos os seus diretórios pais.

Estruturação do código-fonte

O exemplo a seguir mostra como os arquivos TEST_MAPPING podem ser configurados na árvore de origem.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Conteúdo do src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Conteúdo do src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Conteúdo do src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Especificando diretórios de destino

Você pode especificar um diretório de destino para executar testes em arquivos TEST_MAPPING nesse diretório. O comando a seguir executará dois testes (A, B).

atest --test-mapping src/project_1

Executar regras de teste pós-envio

Você também pode usar este comando para executar as regras de teste postsubmit definidos no TEST_MAPPING em src_path (padrão para CWD) e seus diretórios pai:

atest [--test-mapping] [src_path]:postsubmit

Executando apenas testes que não requerem nenhum dispositivo

Você pode usar a opção --host para Atest para testes só são executados configurados contra o host que requerem nenhum dispositivo. Sem essa opção, o Atest executará os dois testes, os que exigem dispositivo e os que são executados no host e não exigem dispositivo. Os testes serão executados em duas suítes separadas.

atest [--test-mapping] --host

Identificando grupos de teste

Você pode especificar grupos de teste no comando Atest. O seguinte comando irá executar todos os testes postsubmit relacionados aos arquivos no diretório src / project_1, que contém apenas um teste (C).

Ou você pode usar: tudo para executar todos os testes, independentemente do grupo. O comando a seguir executa quatro testes (A, B, C, X):

atest --test-mapping src/project_1:all

Incluindo subdiretórios

Por padrão, a execução de testes em TEST_MAPPING com Atest executará apenas testes de pré-envio configurados no arquivo TEST_MAPPING em CWD (ou diretório fornecido) e seus diretórios pais. Se você deseja executar testes em todos os arquivos TEST_MAPPING nas sub-diretórios, use a opção --include-subdir para forçar Atest para incluir esses testes também.

atest --include-subdir

Sem a --include-subdir opção, Atest irá executar apenas teste A. Com o --include-subdir opção, Atest irá correr dois testes (A, B).

Comentário em nível de linha é suportado

Você pode adicionar um nível de linha // comentário -format à carne para fora o arquivo TEST_MAPPING com uma descrição da definição que se segue. ATest e Federação do Comércio vai pré-processar o TEST_MAPPING para um formato JSON válida sem comentários. Para manter o arquivo JSON limpo e fácil de ler, só de nível de linha // comentário -format é suportado.

Exemplo:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}