Práticas recomendadas para execução de ambientes de teste personalizados

Confie no software gerenciado do Device Farm e nos recursos da API para executar a configuração sempre que possível, em vez de aplicar configurações semelhantes por meio de comandos shell no arquivo de especificação de teste. Isso inclui a configuração do host de teste e do dispositivo, pois será mais sustentável e consistente em todos os hosts e dispositivos de teste.

Embora o Device Farm incentive você a personalizar seu arquivo de especificação de teste o quanto for necessário para executar seus testes, a manutenção do arquivo de especificação de teste pode se tornar difícil com o tempo, à medida que mais comandos personalizados são adicionados a ele. Usando o software gerenciado do Device Farm (por meio de ferramentas como devicefarm-cli e as ferramentas padrão disponíveis no$PATH) e usando recursos gerenciados (como o parâmetro de deviceProxysolicitação) para simplificar o arquivo de especificação de teste, transferindo a responsabilidade da manutenção para o próprio Device Farm.

Não use caminhos absolutos nem confie em versões secundárias específicas em seu arquivo de especificação de teste ou código de pacote de teste. O Device Farm aplica atualizações de rotina ao host de teste selecionado e às versões de software incluídas. Usar caminhos específicos ou absolutos (como /usr/local/bin/python em vez depython) ou exigir versões secundárias específicas (como Node.js 20.3.1 em vez de apenas 20) pode fazer com que seus testes não consigam localizar o arquivo /executável necessário.

Como parte da execução personalizada do teste, o Device Farm configura várias variáveis de ambiente e a $PATH variável para garantir que os testes tenham uma experiência consistente em nossos ambientes dinâmicos. Consulte Variáveis de ambiente para ambientes de teste personalizados e Software compatível em ambientes de teste personalizados para obter mais informações.

Salve os arquivos gerados ou copiados no diretório temporário durante a execução do teste. Hoje, garantimos que o diretório temporário (/tmp) esteja acessível ao usuário durante a execução do teste (além dos diretórios gerenciados, como o$DEVICEFARM_LOG_DIR). Outros diretórios aos quais o usuário tem acesso podem mudar com o tempo devido às necessidades do serviço ou do sistema operacional em uso.

Salve seus registros de execução de teste em $DEVICEFARM_LOG_DIR. Esse é o diretório de artefatos padrão fornecido para sua execução para adicionar logs/artefatos de execução. Cada um dos exemplos de especificações de teste que fornecemos usa esse diretório para artefatos por padrão.

Certifique-se de que seus comandos retornem um código diferente de zero em caso de falha durante a test fase de sua especificação de teste. Determinamos se sua execução falhou verificando se há um código de saída diferente de zero de cada comando shell invocado durante a test fase. Você deve garantir que sua lógica ou estrutura de teste retorne um código de saída diferente de zero para todos os cenários desejados, o que pode exigir configuração adicional.

Por exemplo, certas estruturas de teste (como JUnit5) não consideram a execução de zero testes uma falha, o que fará com que seus testes sejam detectados como tendo sido executados com êxito, mesmo que nada tenha sido executado. Usando JUnit5 como exemplo, você precisaria especificar a opção de linha de comando --fail-if-no-tests para garantir que esse cenário saia com um código de saída diferente de zero.

Analise a compatibilidade do software com a versão do sistema operacional do dispositivo e a versão do host de teste que você usará para a execução do teste. Por exemplo, há certos recursos nas estruturas de software de teste (por exemplo: Appium) que podem não funcionar conforme o esperado em todas as versões do sistema operacional do dispositivo que está sendo testado.

Evite armazenar ou registrar variáveis confidenciais (como chaves da AWS) em seu arquivo de especificação de teste. Os arquivos da especificação de teste, os scripts gerados pela especificação de teste e os registros do script da especificação de teste são todos fornecidos como artefatos que podem ser baixados no final da execução do teste. Isso pode levar à exposição não intencional de segredos para outros usuários em sua conta com acesso de leitura ao seu teste.