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

Configuração de teste complexo

Alguns módulos de teste podem exigir configuração personalizada e etapas de desmontagem que não podem ser executadas no próprio caso de teste. Exemplos típicos podem incluir:

  • instalar outros apks (além do apk de teste)
  • envie alguns arquivos para o dispositivo
  • executar comandos (por exemplo, adb shell pm ...)

No passado, as equipes de componentes geralmente recorriam à escrita de um teste do lado do host para executar tais tarefas, o que requer a compreensão do controle da Federação do Comércio e normalmente aumenta a complexidade de um módulo de teste.

Pegando emprestado do CTS, introduzimos o conceito de configuração do módulo de teste para suportar tais tarefas, a lista de tarefas comuns acima pode ser alcançada por apenas algumas linhas de configuração. Para maior flexibilidade, você ainda pode implementar seu próprio preparador alvo, tal como definido pela ITargetPreparer ou ITargetCleaner , e configurá-los para usar em seu próprio módulo de teste de configuração.

Uma configuração de módulo de teste para um módulo de teste é um arquivo XML necessário adicionado à pasta de origem do módulo de nível superior, denominado 'AndroidTest.xml'. O XML segue o formato de um arquivo de configuração usado pelo equipamento de automação de teste da Trade Federation. Atualmente, as principais tags tratadas por meio das configurações do módulo de teste são as tags “target_preparer” e "test".

Preparadores de alvo

A tag “target_preparer”, como o nome sugere, define um preparador alvo (veja ITargetPreparer ) que oferece um método de configuração, que é chamado antes do módulo de teste é executado para testar; e se a classe referenciado na tag “target_preparer” também implementa ITargetCleaner , seu método de desmontagem será invocado depois que o módulo de teste foi concluída.

Para usar a configuração do módulo comum integrado, adicione um novo arquivo 'AndroidTest.xml' na pasta de nível superior do seu módulo de teste e preencha-o com o seguinte conteúdo:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

Como exemplo, podemos adicionar as seguintes tags de opção (no comentário “inserir” acima):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

As opções irão configurar o equipamento de teste para:

  1. antes que o módulo de teste seja invocado, execute o comando shell "settings colocar acessibilidade segura_enabled 1" no dispositivo
  2. após a conclusão do módulo de teste, execute o comando shell "settings colocar acessibilidade segura_enabled 0"

Neste exemplo específico, a acessibilidade é habilitada / desabilitada antes / depois da execução do módulo de teste, respectivamente. Com um exemplo simples demonstrado, é necessário cobrir mais detalhes sobre como a tag “opção” é usada. Conforme mostrado acima, a tag pode ter dois atributos: nome, valor. O atributo name indicava o nome da opção e é subdividido em duas partes separadas por dois pontos: nome abreviado do preparador e o nome da opção real oferecido pelo preparador.

A finalidade exata do campo de valor depende de como o preparador definiu a opção: pode ser uma string, um número, um booleano ou até mesmo um caminho de arquivo etc. No exemplo acima, o nome “run-command: run-command” significa que estamos definindo o valor para a opção “run-command” definida por um preparador de destino com o nome abreviado “run-command”; e o nome “run-command: teardown-command” significa que estamos definindo o valor para a opção “teardown-command” também definida pelo mesmo preparador de destino com o nome abreviado “run-command”. Aqui está um resumo dos três preparadores de alvo comuns:

  • nome da classe: PushFilePreparer

    • nome curto: push-arquivo
    • função: empurra arquivos arbitrários sob pasta caso de teste em destino no dispositivo
    • notas:
      • este preparador pode enviar de uma pasta para outra ou de um arquivo para outro; ou seja, você não pode enviar um arquivo por push em uma pasta no dispositivo: você também deve especificar o nome do arquivo de destino nessa pasta
    • opções:
      • push: Um impulso-spec, formatado como ' /path/to/srcfile.txt->/path/to/destfile.txt ' ou ' /path/to/srcfile.txt->/path/to/destdir/ '. Pode ser repetido. Este caminho pode ser relativo ao diretório do módulo de teste ou ao próprio diretório de saída.
      • ** pós-push: comando ** A para executar no dispositivo (com ` adb shell <your command> `) depois de todos os empurrões foram tentadas. Caso de uso típico seria usar chmod para permissões
  • nome da classe: InstallApkSetup

    • nome curto: instalar-apk
    • função: empurra arquivos APK arbitrárias sob a destino no dispositivo
    • opções:
      • test-file-name: o nome do apk para ser instalado no para o dispositivo.
      • instalar-arg: Argumentos adicionais a serem passados para o pm comando de instalação, incluindo levando traço, por exemplo, “-d" Pode ser repetido.
  • nome da classe: RunCommandTargetPreparer

    • nome curto: gerência de comando
    • Função: Executa o arbitrário comandos shell antes ou depois da execução módulo de teste
    • opções:
      • gerência de comando: comando adb shell para executar. Pode ser repetido
      • teardown-comando: comando adb shell para executar durante a desmontagem de fase. Pode ser repetido

Aula de teste

Uma classe de teste é a classe Trade Federation a ser usada para executar o teste.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Aqui estão três classes de teste comuns:

  • nome da classe: gtest

    • nome curto: gtest
    • função: Um teste que corre um pacote de teste nativo no dado dispositivo.
    • opções:
      • -teste de dispositivo de caminho nativo: O caminho no dispositivo, onde os testes nativas estão localizados.
  • nome da classe: InstrumentationTest

    • nome curto: de instrumentação
    • função: Um teste que corre um pacote de teste instrumentação em determinado dispositivo
    • opções:
      • pacote: O nome do pacote manifesto do aplicativo de teste Android para executar.
      • class: O nome da classe de teste para executar.
      • Método: O nome do método de teste para executar.
  • nome da classe: AndroidJUnitTest

    • função: Um teste que corre um pacote de teste instrumentação em determinado dispositivo usando o android.support.test.runner.AndroidJUnitRunner Esta é a principal forma de executar um teste de instrumentação.