Configuração de teste complexa

Alguns módulos de teste podem exigir etapas de configuração e encerramento personalizadas que não podem ser realizadas no próprio caso de teste. Exemplos típicos incluem:

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

No passado, as equipes de componentes geralmente recorriam à gravação de um teste do lado do host para realizar essas tarefas, o que exige o entendimento do harness do Trade Federation e normalmente aumenta a complexidade de um módulo de teste .

Inspirado no CTS, introduzimos o conceito de configuração do módulo de teste para oferecer suporte a essas tarefas. A lista de tarefas comuns acima pode ser realizada com apenas algumas linhas de configuração. Para ter a máxima flexibilidade, você pode até mesmo implementar seu próprio preparador de destino, conforme definido por ITargetPreparer ou ITargetCleaner, e configurá-los para usar na sua própria configuração de módulo de teste.

Uma configuração de módulo de teste é um arquivo XML obrigatório adicionado à pasta de origem do módulo de nível superior, chamado "AndroidTest.xml". O XML segue o formato de um arquivo de configuração usado pelo arnês de automação de teste do Trade Federation. No momento, as principais tags processadas pelas configurações do módulo de teste são "target_preparer" e "test".

Preparadores de destino

Uma tag "target_preparer", como o nome sugere, define um preparador de destino (consulte ITargetPreparer) que oferece um método de configuração, que é chamado antes da execução do módulo de teste para testes. Se a classe referenciada na tag "target_preparer" também implementar ITargetCleaner, o método de desmontagem será invocado após a conclusão do módulo de teste.

Para usar a configuração do módulo comum integrada, adicione um novo arquivo "AndroidTest.xml" na pasta de nível superior do módulo de teste e preencha 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>

Por exemplo, podemos adicionar as seguintes tags de opção (no comentário "insert" 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 vão configurar o ambiente de teste para:

  1. antes que o módulo de teste seja invocado, execute o comando do shell "settings put secure accessibility_enabled 1" no dispositivo
  2. Depois que o módulo de teste for concluído, execute o comando do shell "settings put secure accessibility_enabled 0"

Neste exemplo específico, a acessibilidade é ativada/desativada antes/depois da execução do módulo de teste, respectivamente. Com um exemplo simples demonstrado, é necessário abordar mais detalhes sobre como a tag "option" é usada. Como mostrado acima, a tag pode ter dois atributos: nome e valor. O atributo "name" precisa se referir a uma das opções oferecidas pelo preparador.

O objetivo exato do campo "value" 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. Confira um resumo dos três preparadores de destino comuns:

  • Nome da classe: PushFilePreparer

    • Nome abreviado: push-file
    • function: envia arquivos arbitrários da pasta de caso de teste para o destino no dispositivo
    • Observações:
      • esse preparador pode enviar de pasta para pasta ou de arquivo para arquivo. Ou seja, não é possível enviar um arquivo em uma pasta no dispositivo. É necessário especificar o nome do arquivo de destino nessa pasta também.
    • options:
      • push-file:uma especificação de envio, especificando o arquivo local para o caminho em que ele deve ser enviado por push no dispositivo. Pode ser repetido. Se vários arquivos forem configurados para serem enviados por push para o mesmo caminho remoto, o mais recente será enviado.
      • push:(descontinuado) uma especificação de push, formatada como '/path/to/srcfile.txt->/path/to/destfile.txt' ou '/path/to/srcfile.txt->/path/to/destdir/'. Pode ser repetida. Esse caminho pode ser relativo ao diretório do módulo de teste ou ao diretório de saída.
      • post-push:um comando a ser executado no dispositivo (com adb shell <your command>) depois que todas as tentativas de push forem feitas. Um caso de uso típico seria usar chmod para permissões

  • Nome da classe: InstallApkSetup

    • nome curto:install-apk
    • function:envia arquivos APK arbitrários para o destino no dispositivo.
    • options:
      • test-file-name:o nome do APK a ser instalado no dispositivo.
      • install-arg:argumentos extras a serem transmitidos ao comando pm install, incluindo o traço inicial, por exemplo, "-d". Pode ser repetido

  • Nome da classe: RunCommandTargetPreparer

    • Nome abreviado:run-command
    • function:executa comandos de shell arbitrários antes ou depois da execução do módulo de teste.
    • options:
      • run-command:comando adb shell a ser executado. Pode ser repetido
      • teardown-command:comando adb shell a ser executado durante a fase de desmontagem. Pode ser repetido

Classe de teste

Uma classe de teste é a classe do Trade Federation 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>

Confira três classes de teste comuns:

  • Nome da classe: GTest

    • Nome abreviado:gtest
    • function:um teste que executa um pacote de teste nativo em um determinado dispositivo.
    • options:
      • native-test-device-path:o caminho no dispositivo onde os testes nativos estão localizados.

  • Nome da classe: InstrumentationTest

    • Nome abreviado:instrumentação
    • function:um teste que executa um pacote de teste de instrumentação em um determinado dispositivo.
    • options:
      • package:o nome do pacote do manifesto do aplicativo de teste do Android a ser executado.
      • class:o nome da classe de teste a ser executada.
      • method:o nome do método de teste a ser executado.

  • Nome da classe: AndroidJUnitTest

    • function:um teste que executa um pacote de teste de instrumentação no dispositivo especificado usando android.support.test.runner.AndroidJUnitRunner. Essa é a principal maneira de executar um teste de instrumentação.