Configuração de teste complexa

Alguns módulos de teste podem exigir etapas de configuração e remoção personalizadas que não podem ser realizadas no próprio caso de teste. Exemplos comuns podem incluir:

  • 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 recorrem à criação de um teste do lado do host para realizar essas tarefas, o que requer a compreensão do arcabouço da Trade Federation e, normalmente, aumenta a complexidade de um módulo de teste .

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

Uma configuração de módulo de teste para um módulo de teste é um arquivo XML obrigatório adicionado ao topo da pasta de origem do módulo, chamada "AndroidTest.xml". O XML segue o formato de um arquivo de configuração usado pelo arcabouço de automação de testes da Trade Federation. No momento, as principais tags gerenciadas pelas configurações do módulo de teste são “target_preparer” e "teste" .

Preparadores de segmentação

A tag "target_preparer", como o nome sugere, define um preparador de segmentação (consulte ITargetPreparer). que oferece um método de configuração, que é chamado antes que o módulo de teste seja executado para testes. e se a classe referenciada na tag “target_preparer” também implementa ITargetCleaner, o método de desmontagem será invocado após a conclusão do módulo de teste.

Para usar a configuração integrada do módulo comum, adicione um novo arquivo "AndroidTest.xml" em pasta de nível superior para seu módulo de teste e preenchê-la com as seguintes 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 configurarão o arcabouço de testes para:

  1. antes que o módulo de teste seja invocado, execute o comando shell “settings put secure access_enabled 1” no dispositivo
  2. depois que o módulo de teste for concluído, execute o comando shell “settings put secure acessibilidade_enabled 0”

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

A finalidade exata do campo de valor depende de como o preparador foi definido 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 curto: push-file
    • function: envia arquivos arbitrários da pasta de casos de teste para destino no dispositivo
    • observações:
      • Esse preparador pode enviar de uma pasta para outra ou de um arquivo para outro. 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.
    • opções:
      • push-file:uma especificação push que especifica o arquivo local para o caminho. para onde ele deve ser enviado no dispositivo. Pode ser repetido. Se vários arquivos estiverem configurados para serem enviados para o mesmo caminho remoto, o mais recente será enviado.
      • push: (descontinuado) uma especificação push, formatada como "/path/to/srcfile.txt->/path/to/destfile.txt" ou "/path/to/srcfile.txt->/path/to/destdir/". Pode ser repetido. Esse caminho pode ser relativo ao diretório do módulo de teste ou ao diretório em si.
      • post-push: um comando para ser executado no dispositivo (com "adb shell <your command>") depois que todos os pushes forem tentados. Uso normal caso seria usar chmod para permissões
  • Nome da classe: InstallApkSetup

    • short name:install-apk
    • function:envia arquivos apk arbitrários para o destino no dispositivo
    • opções:
      • test-file-name:o nome do APK a ser instalado no dispositivo.
      • install-arg:argumentos adicionais a serem transmitidos para a instalação pm , incluindo o travessão à esquerda, por exemplo, "-d". Pode ser repetido
  • Nome da classe: RunCommandTargetPreparer.

    • nome curto:run-command
    • função: executa comandos arbitrários do shell antes ou depois do teste execução do módulo
    • opções:
      • run-command:o comando do shell do adb a ser executado. Pode ser repetido
      • teardown-command: o comando adb shell a ser executado durante a fase de eliminação. Pode ser repetido

Classe 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 executa um pacote de teste nativo em um determinado dispositivo.
    • opções:
      • native-test-device-path:o caminho no dispositivo em que os testes nativos estão localizados.
  • Nome da classe: InstrumentationTest

    • nome curto:instrumentação
    • função:um teste que executa um pacote de teste de instrumentação em um determinado dispositivo.
    • opções:
      • package:o nome do pacote de 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

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