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:
- instale outros apks (além do apk de teste)
- enviar alguns arquivos para o dispositivo
- execute comandos (por exemplo, adb shell pm ...)
No passado, as equipes de componentes geralmente recorriam à escrita de um teste do lado do host para realizar tais tarefas, o que requer a compreensão do chicote da Federação de Comércio e normalmente aumenta a complexidade de um módulo de teste .
Tomando 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 com apenas algumas linhas de configuração. Para flexibilidade máxima, você pode até implementar seu próprio preparador de destino, conforme definido por ITargetPreparer ou ITargetCleaner e configurá-los para usar em sua própria configuração de módulo de teste.
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, chamada 'AndroidTest.xml'. O XML segue o formato de um arquivo de configuração usado pelo conjunto de automação de teste da Trade Federation. Atualmente as principais tags manipuladas através das configurações do módulo de teste são as tags “target_preparer” e “test”.
Preparadores de alvo
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 que o módulo de teste seja executado para teste; e se a classe referenciada na tag “target_preparer” também implementar ITargetCleaner , seu método teardown será invocado após o término do módulo de teste.
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 configurarão o equipamento de teste para:
- antes que o módulo de teste seja invocado, execute o comando shell “settings put secure reflection_enabled 1” no dispositivo
- depois que o módulo de teste for concluído, execute o comando shell “settings put secure reflection_enabled 0”
Neste exemplo em particular, 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 “option” é usada. Conforme mostrado acima, a tag pode ter dois atributos: nome, valor. O atributo name indicava o nome da opção e é dividido em duas partes separadas por dois pontos: nome curto para o 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 curto “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 curto “run-command”. Aqui está um resumo dos três preparadores de destino comuns:
nome da classe: PushFilePreparer
- nome curto : arquivo push
- função : envia arquivos arbitrários na pasta de casos de teste para o destino no dispositivo
- notas :
- este preparador pode enviar de pasta para pasta ou arquivo para arquivo; ou seja, você não pode enviar um arquivo para uma pasta no dispositivo: você também deve especificar o nome do arquivo de destino nessa pasta
- opções :
- push-file: uma especificação de push, especificando o arquivo local para o caminho em que ele deve ser enviado por push 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: (obsoleto) 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 repetido. Esse caminho pode ser relativo ao diretório do módulo de teste ou ao próprio diretório de saída. - post-push: Um comando a ser executado no dispositivo (com `
adb shell <your command>`) após todas as tentativas de push. Caso de uso típico seria usar chmod para permissões
nome da classe: InstallApkSetup
- nome curto: install-apk
- função: 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 passados para o comando pm install, incluindo o traço inicial, por exemplo, “-d”. Pode ser repetido
nome da classe: RunCommandTargetPreparer
- nome curto: comando de execução
- função: executa comandos shell arbitrários antes ou depois da execução do módulo de teste
- opções:
- run-command: comando shell adb a ser executado. Pode ser repetido
- comando de desmontagem: comando de shell adb a ser executado durante a fase de desmontagem. 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
- function: Um teste que executa um pacote de teste nativo em um determinado dispositivo.
- opções:
- native-test-device-path: O caminho no dispositivo onde os testes nativos estão localizados.
nome da classe: InstrumentationTest
- nome curto: instrumentação
- function: Um teste que executa um pacote de teste de instrumentação em determinado dispositivo
- opções:
- package: o nome do pacote de manifesto do aplicativo de teste 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 em determinado dispositivo usando o android.support.test.runner.AndroidJUnitRunner Esta é a principal maneira de executar um teste de instrumentação.