As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Práticas recomendadas para execução de ambientes de teste personalizados Os tópicos a seguir abordam as melhores práticas recomendadas para usar a execução de testes personalizados com o Device Farm. **Configuração da execução** + **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 [https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_ScheduleRunConfiguration.html#devicefarm-Type-ScheduleRunConfiguration-deviceProxy)solicitação) para simplificar o arquivo de especificação de teste, transferindo a responsabilidade da manutenção para o próprio Device Farm. **Especificação de teste e código do pacote de teste** + **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 de`python`) 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](custom-test-environment-variables.md) e [Software compatível em ambientes de teste personalizados](custom-test-environments-hosts-software.md) 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](custom-test-environment-test-spec.md#custom-test-environment-test-spec-example) 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. **Segurança** + **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.