This is the multi-page printable view of this section. Click here to print.
Piores práticas
1 - Captchas
CAPTCHA, abreviação de Completely Automated Public Turing test to tell Computers and Humans Apart, foi projetado explicitamente para impedir a automação, portanto, não tente! Existem duas estratégias principais para contornar as verificações CAPTCHA:
- Desative CAPTCHAs em seu ambiente de teste
- Adicione um hook para permitir que os testes ignorem o CAPTCHA
2 - Downloads de arquivo
Embora seja possível iniciar um download clicando em um link com um navegador sob o controle do Selenium, a API não expõe o progresso do download, tornando-o menos do que ideal para testar arquivos baixados. Isso ocorre porque o download de arquivos não é considerado um aspecto importante de emular a interação do usuário com a plataforma da web. Em vez disso, encontre o link usando Selenium (e todos os cookies necessários) e passe este cookie para uma biblioteca de solicitação HTTP como libcurl.
O driver HtmlUnit pode baixar anexos acessando-os como fluxos de entrada, implementando o AttachmentHandler. O AttachmentHandler pode ser adicionado ao WebClient HtmlUnit.
3 - Códigos de respostas HTTP
Para algumas configurações de navegador no Selenium RC,
Selenium atuou como um proxy entre o navegador
e o site sendo automatizado.
Isso significa que todo o tráfego do navegador que passou pelo Selenium
poderia ser capturado ou manipulado.
O método captureNetworkTraffic()
pretendia capturar todo o tráfego de rede entre o navegador
e o site sendo automatizado,
incluindo códigos de resposta HTTP.
Selenium WebDriver é uma abordagem completamente diferente para a automação do navegador, preferindo agir mais como um usuário. Isso é representado na maneira como você escreve testes com o WebDriver. Em testes funcionais automatizados, verificar o código de status não é um detalhe particularmente importante da falha de um teste; as etapas que o precederam são mais importantes.
O navegador sempre representará o código de status HTTP,
imagine, por exemplo, uma página de erro 404 ou 500.
Uma maneira simples de “falhar rapidamente” quando você encontrar uma dessas páginas de erro
é verificar o título da página ou o conteúdo de um ponto confiável
(por exemplo, a tag <h1>) após cada carregamento de página.
Se você estiver usando o modelo de objeto de página,
você pode incluir esta verificação em seu construtor de classe
ou ponto semelhante onde o carregamento da página é esperado.
Ocasionalmente, o código HTTP pode até ser representado
na página de erro do navegador
e você pode usar o WebDriver para ler isso
e melhorar sua saída de depuração.
Verificar se a própria página da web está alinhada com a prática ideal do WebDriver de representar a visão do usuário do site.
Se você insiste, uma solução avançada para capturar códigos de status HTTP é replicar o comportamento do Selenium RC usando um proxy. A API WebDriver fornece a capacidade de definir um proxy para o navegador, e há uma série de proxies que irão permitir que você manipule de forma programática o conteúdo das solicitações enviadas e recebidas do servidor da web. Usar um proxy permite que você decida como deseja responder para códigos de resposta de redirecionamento. Além disso, nem todo navegador torna os códigos de resposta disponíveis para WebDriver, então optar por usar um proxy permite que você tenha uma solução que funciona para todos os navegadores.
4 - Login via Gmail, email e Facebook
Por vários motivos, fazer login em sites como Gmail e Facebook usando do WebDriver não é recomendado. Além de ser contra os termos de uso desses sites (onde você corre o risco de ter a conta encerrada), é lento e não confiável.
A prática ideal é usar as APIs que os provedores de e-mail oferecem, ou no caso do Facebook, o serviço de ferramentas para desenvolvedores que expõe uma API para criar contas de teste, amigos e assim por diante. Embora usar uma API possa parecer um pouco trabalhoso, você será recompensado em velocidade, confiabilidade e estabilidade. A API também não deve mudar, enquanto as páginas da web e os localizadores de HTML mudam frequentemente e exigem que você atualize sua estrutura de teste.
Login em sites de terceiros usando WebDriver em qualquer ponto do seu teste aumenta o risco de seu teste falhar porque torna o teste mais longo. Uma regra geral é que testes mais longos são mais frágeis e não confiáveis.
Implementações WebDriver que estão
em conformidade com W3C
também anotam o objeto navigator
com uma propriedade WebDriver
para que os ataques de negação de serviço possam ser mitigados.
5 - Dependência entre testes
Uma ideia comum e um equívoco sobre o teste automatizado é sobre uma ordem de testes específica. Seus testes devem ser executados em qualquer ordem, e não depender da conclusão de outros testes para ter sucesso.
6 - Teste de performance/desempenho
Teste de desempenho usando Selenium e WebDriver geralmente não é recomendado. Não porque é incapaz, mas porque não é otimizado para o trabalho e é improvável que você obtenha bons resultados.
Pode parecer ideal para teste de desempenho no contexto do usuário, mas um conjunto de testes WebDriver estão sujeitos a muitos pontos de fragilidade externa e interna que estão além do seu controle; por exemplo, velocidade de inicialização do navegador, velocidade dos servidores HTTP, resposta de servidores de terceiros que hospedam JavaScript ou CSS, e a penalidade de instrumentação da própria implementação do WebDriver. A variação nesses pontos causará variação em seus resultados. É difícil separar a diferença entre o desempenho do seu site e o desempenho de recursos externos, e também é difícil dizer qual é a penalidade de desempenho para usar WebDriver no navegador, especialmente se você estiver injetando scripts.
A outra atração potencial é “economizar tempo” - execução de testes funcionais e de desempenho ao mesmo tempo. No entanto, os testes funcionais e de desempenho têm objetivos opostos. Para testar a funcionalidade, um testador pode precisar ser paciente e aguarde o carregamento, mas isso irá turvar os resultados do teste de desempenho e vice-versa.
Para melhorar o desempenho do seu site, você precisará ser capaz de analisar o desempenho geral independente das diferenças de ambiente, identificar práticas de código ruins, repartição do desempenho de recursos individuais (ou seja, CSS ou JavaScript), para saber o que melhorar. Existem ferramentas de teste de desempenho disponíveis que podem fazer este trabalho, que fornecem relatórios e análises, e podem até fazer sugestões de melhorias.
Pacotes de exemplo (código aberto) a serem usados são: JMeter
7 - Navegação por links
Usar o WebDriver para navegar por links não é uma prática recomendada. Não porque não pode ser feito, mas porque WebDriver definitivamente não é a ferramenta ideal para isso. O WebDriver precisa de tempo para inicializar, e pode levar vários segundos, até um minuto dependendo de como seu teste é escrito, apenas para chegar à página e atravessar o DOM.
Em vez de usar o WebDriver para isso, você poderia economizar muito tempo executando um comando curl, ou usando uma biblioteca como BeautifulSoup uma vez que esses métodos não dependem em criar um navegador e navegar para uma página. Você está economizando muito tempo por não usar o WebDriver para essa tarefa.
8 - Autenticação de Dois Fatores (2FA)
A autenticação de dois fatores, conhecida como 2FA, é um mecanismo de autorização onde a senha de uso único (OTP) é gerada usando aplicativos móveis “Autenticadores”, como “Google Authenticator”, “Microsoft Authenticator” etc., ou por SMS, e-mail para autenticação. Automatizar isso perfeitamente e consistentemente é um grande desafio no Selenium. Existem algumas maneiras para automatizar este processo. Mas essa será outra camada em cima de nossos testes Selenium e não protegidos também. Portanto, você pode evitar a automação do 2FA.
Existem algumas opções para contornar as verificações 2FA:
- Desative 2FA para determinados usuários no ambiente de teste, para que você possa usar essas credenciais de usuário na automação.
- Desative 2FA em seu ambiente de teste.
- Desative 2FA se você fizer o login de determinados IPs. Dessa forma, podemos configurar nosso teste os IPs da máquina para evitar isso.
