Como funciona o selênio: episódios 1 - 2

Uma tradução do artigo foi preparada antes do início do curso Java QA Engineer .



Episódio 1 - Transporte


Como resultado do diálogo ocorrido no último final de semana de janeiro de 2020, dedicado a um dos problemas do Selenium, onde alguém me disse "por que você simplesmente não faz isso ..." em resposta à explicação do problema, decidi escrever uma série de artigos explicando os comandos no Selenium WebDriver e por que acabamos com o design que temos hoje.

Vou repetir isso em todos os episódios desta série - muito, às vezes até o ponto da loucura, muito pensamento e pensamento foram colocados no trabalho de todos os mínimos detalhes do Selenium.

Por quê?

Por acaso e quão bem ele faz o que se destina a fazer, o Selenium é usado por milhões de pessoas em todo o mundo. É assim que a maior variedade de empresas, de pequenas empresas iniciantes a Microsoft e Google, garante que o site funcione em todos os navegadores.

Selenium ?


Ao longo dos anos do Selenium, acabamos focando no uso do HTTP como uma maneira de interagir com o navegador. Criamos a API REST-ish (REST-ish - no espírito do REST), que pode usar cada ligação de cliente e obter, esperamos, os mesmos resultados.

HTTP e REST-ish? A sério?

Sim ...

Vamos começar com a parte HTTP. Quando começamos, tivemos que oferecer suporte a diferentes maneiras de interagir com cada navegador, com base na melhor abordagem para cada um deles. Por exemplo, para o Internet Explorer, escrevemos código COM. Ele trabalhou bem, mas dele ainda temos pesadelos. Para o Firefox, escrevemos um monstro de leitura linha por linha, que, felizmente, graças à abordagem "faça seu navegador" da Mozilla, era capaz de muito. O Opera nos permitiu entrar através do protocolo DevTools.

Portanto, isso significava que, especialmente nos primeiros anos do WebDriver, precisávamos oferecer suporte a ligações N: M, onde N são as ligações de idiomas e M são os navegadores suportados. Esse caminho não leva a um bom produto. Decidimos que precisávamos de algo que todas as línguas entendessem. Também precisávamos de algo bastante confiável. Então a escolha caiu no HTTP, e começamos a criar JSONWireProtocol.

Na estrutura, JSONWireProtocolcriamos uma interface REST-ish que se comunica em JSON. Digo REST-ish porque não segue absolutamente todos os princípios do REST, mas os incorpora a um grau suficiente para torná-lo uma ferramenta poderosa para nossas tarefas.

E o estado atual das coisas?

Web, Internet e o mundo seguem em frente. Então, por que o Selenium não é?

Essa é uma boa pergunta, mas o fato é que estamos tentando modernizar. Infelizmente, a rede é caracterizada por um estado em que não funciona, se não estiver em execução. O HTTP é bastante confiável como um protocolo. Ele também permite que as pessoas criem clusters para teste sem se preocupar com o funcionamento da multiplexação. Esta é a razão pela qual o Selenium Grid foi criado, o que ainda é uma boa opção quando se trata de organizar testes com vários dispositivos e computadores.

Mas parece mais uma rede.

Então ... Existem ferramentas que usam o Chrome Debug Protocol para controlar o Chrome. Eles fazem algumas coisas melhor que o Selenium, que é uma conseqüência da escolha de como se comunicar com o navegador. Infelizmente, esse é o protocolo proprietário do Chrome, e torná-lo acessível a outros navegadores não é do interesse do Google.

Além disso, ignorando soluções interessantes de design da equipe do Google, existe um problema que precisamos ter uma conexão constantemente aberta. Nesse caso, ele usa WebSockets, mas você deve se lembrar do meu comentário acima de que a Internet não está disponível enquanto não está funcionando. O WebSockets se reconectará constantemente. Há também o problema de quanto tráfego vai subir e descer neste canal.

Isso não é um problema para o apresentador de marionetes quando você interage com algo apenas no computador local, mas se você integrar um serviço de IC, como Circle CI ou TravisCI e algo como AWS Device Farm, Sauce Labs ou BrowserStack, entre você e seu corredor de repente obtém a Internet e esses dados devem chegar aos destinatários.

O grupo de trabalho W3C Browser Testing and Tools, composto por fornecedores de navegadores e pessoal do Selenium, está tentando projetar como tudo deve parecer para garantir que possamos garantir a compatibilidade entre navegadores desde o início, sem recorrer a patches estranhos de hackers e entrega pessoal desses navegadores.

Quer saber mais?



Episódio 2 - Navegação
Neste episódio, veremos uma enorme quantidade de trabalho relacionado à navegação.

from selenium import webdriver

driver = webdriver.Firefox()
driver.get("https://www.theautomatedtester.co.uk")


O que vemos acima ... parece bem simples, certo ... mas aqui está!

De fato, isso me leva a uma entrevista insensível. Se alguém pedir para você descrever o que acontece no navegador quando você digita o URL e pressiona enter, há uma alta probabilidade de que ele não tenha uma idéia real do que está acontecendo na navegação. Enfim ... de volta ao Selenium e sua navegação. Assim que enviamos a solicitação pela camada de transporte , a verdadeira diversão começa. Precisamos descobrir para onde queremos ir e dizer ao navegador para ir lá para nós. Infelizmente, isso levará ao primeiro de muitos problemas de automação.

driver.get



Certificados


Se você já trabalhou em grandes empresas corporativas, onde a tecnologia não é a principal, você entende que tipo de dor a equipe de desenvolvimento pode enfrentar. Agora, dobre essa dor e você pode imaginar a dor com a qual os testadores e engenheiros de automação precisam lidar.

Uma dessas dores são os certificados. As empresas são mesquinhas e fazem certificados autoassinados e outras deformidades. Especialmente nos primeiros dias do Selenium, quando não havia serviços como o Let's Encrypt . E mesmo agora, a maioria dos desenvolvedores e grupos de controle de qualidade raramente têm acesso a alterações na configuração em seus ambientes de teste ou em seus servidores de IC. Precisávamos encontrar uma maneira de contornar os certificados. ( Essa é uma das primeiras razões pelas quais o Selenium é visto como um risco à segurança. )

Assim, cada um dos navegadores ignora certificados mal configurados durante a automação. Se eles não tivessem percebido isso, muitos testadores / desenvolvedores não teriam a oportunidade de testar seus sites.

Agora ... quando resolvemos o primeiro problema, precisamos continuar carregando a página.

Carregando


Assim que recebemos os certificados, obtemos a página para download. Felizmente, não precisamos fazer nada mais complicado que o equivalente

location = "https://www.theautomatedtester.co.uk"; 
// 
window.location.href = "https://www.theautomatedtester.co.uk";


Feito ...


Quando o Selenium "concluir" a equipe, receberemos um reembolso. Portanto, basta aguardar o carregamento da página. Para ser completamente franco, o que significa "carregamento concluído" ?

O navegador disparará vários eventos diferentes. Saberemos quando a página será exibida e depois o que é readyState. O selênio testará tudo isso e também esperará DOMContentLoaded.

E então surge um problema se você estiver em uma página e tentando pular para a âncora nessa página. Vejamos o exemplo a seguir.

from selenium import webdriver

driver = webdriver.Firefox()
driver.get("https://www.theautomatedtester.co.uk")
driver.get("https://www.theautomatedtester.co.uk#someAnchor")


Oh, apenas olhe, nenhum dos eventos de carregamento da página será acionado! Classe? Um navegador estúpido funcionará com eficiência e basta rolar para a âncora. Isso significa que não podemos depender apenas dos eventos que emanam da página.

Não, portanto, precisamos de um código especial para este caso e uma compreensão do que "pronto" significa neste caso. Se cometermos um erro, isso criará muitos testes instáveis. Testes instáveis ​​deixam as pessoas mal-humoradas, e não queremos desenvolvedores mal-humorados, existem muitos deles no mundo e sem testes instáveis.

Depois de concluirmos essas verificações, você poderá manipular a maneira como olhamos para esses eventos, se desejar que eles carreguem mais rapidamente usando Estratégias de carregamento de página. Esse é mais um recurso do usuário da pavimentadora, então não me preocuparia com eles agora, mas eles afetam a velocidade dos comandos de navegação.

E as estruturas e navegação JavaScript


Este é o lugar onde toda a "diversão" está concentrada. Muitas estruturas ainda carregam muito após o carregamento inicial na página. Se você já trabalhou em um aplicativo de página única ou apenas o usou, viu muitos elementos sendo exibidos à medida que eles são carregados. Infelizmente, isso significa que você não pode confiar apenas no retorno do comando de navegação. Você precisará adicionar um comando WebDriverWaitao seu código, como mostrado abaixo, para garantir que seu teste esteja no estado correto antes de fazer o que é necessário.

from selenium import webdriver
from selenium.webdriver.support.wait import WebDriverWait

driver = webdriver.Firefox()
driver.get("https://www.theautomatedtester.co.uk")
element = WebDriverWait(driver, 10).until(lambda x: x.find_element_by_id(“someId”))


Conclusão


Ao carregar uma página, nem sempre o Selenium retornará quando a página terminar de carregar. Se você precisar olhar para um elemento em uma página, faça-o. Saiba como o JavaScript na página pode alterá-lo após o carregamento inicial.

Para leitura adicional






Saiba mais sobre o curso .



All Articles