Os princípios de testes E2E com Protractor
O conteúdo a seguir tem como objetivo explicar os conceitos básicos de testes end-to-end, e é destinado a desenvolvedores (ou curiosos) que estão iniciando sua jornada com a ferramenta.
Testes E2E servem para automatizar a interação com aplicações web tal como um usuário faria, e o framework Protractor foi desenvolvido para viabilizar isso.
Como inicialmente foi projetado para aplicações com o falecido AngularJS — que deus o tenha — , ele também é executado em Node, utilizando o WebDriverJS para manipulação dos elementos da página web.
Ainda que seu desenvolvimento tenha os alicerces no Angular, no qual se baseia este artigo, o Protractor pode também ser utilizado em conjunto a outros tipos de aplicações, uma vez que fornece além dos seletores Angular (binding, model, repeat e afins) os populares de atributos HTML como id e class.
De maneira enxuta e superficial, o fluxo ocorre da seguinte maneira (mais adiante falarei mais a respeito de cada termo):
- Início da execução;
- O protractor instância um servidor Selenium para os testes;
- O arquivo de configuração (configuration file) é lido;
- É realizado a busca dos arquivos de teste (spec’s) para execução;
- Ao final, é apresentado os resultados dos testes.
Selenium, é de comer? 🤤
Não. Keep calm young… Em resumo, a Selenium nada mais é do que uma ferramenta que o Protractor utiliza para emular/reproduzir um browser, abstendo o desenvolvedor de ficar reinventando a roda para executar a automatização de “coisas”, como os testes e2e, por exemplo.
O que é o tal do configuration file? 🙄
Devido ao Protractor estar vinculado ao Angular, na criação de um novo projeto é gerado, por default, um arquivo chamado protractor.conf.js (figura 1) na raiz do projeto — bem como a pasta /e2e contendo alguns testes simplórios — , que como o próprio nome indica, contém as configurações que serão utilizadas para execução dos testes.
E o spec file? 🤔
Conforme comentado anteriormente, existe um diretório gerado na criação de um novo projeto (/e2e). Nele, encontra-se o arquivo que executa de fato os casos de testes. Em uma nova aplicação, o arquivo será o app.e2e-spec.ts (figura 2), com o seguinte conteúdo:
Certo, mas e a page object, para que serve mesmo? 🤨
Por fim, mas não menos importante, a PO (Page Object — figura 3). Ela possui os recursos necessários para capturar os elementos que serão utilizados nos casos de testes.
Recomenda-se sua utilização para que, caso ocorra a mudança do nome de classes, id’s e afins no template (HTML) haja mais facilidade na manutenção. Outro benefício dessa boa prática é a reutilização dos métodos de acesso do elemento, que poderão diminuir drasticamente a quantidade de código, se bem aplicados.
Certo, agora vamos ver essa belezura funcionando!
Mesmo que não conheça muito bem, nesta etapa você precisará conter em os seguintes requisitos:
Caso você ainda não tenha um projeto Angular pronto, abra um prompt de comandos apontando para seu workspace e execute o seguinte comando:
> npm new nome_do_projeto
O Protractor pode ser inicializado através de dois principais comandos, sendo ng e2e e/ou protractor seguido pelo nome do arquivo de configuração, além de poder especificar o path de determinado arquivo.
A diferença básica entre os dois é o tempo de execução, onde o ng e2e acaba demorando um pouco mais por construir sua própria plataforma de aplicação. É como se houvesse um ng serve prévio à execução dos testes.
Já o supracitado protractor, poupará mais tempo na elaboração dos testes, porém, será necessário que exista previamente uma plataforma construída de modo que possa ser acessada com a mesma definição contida em baseUrl no arquivo de configuração.
Chega de conversa! Agora que você já tem uma noção básica de como ocorre o fluxo, execute um dos comando citados anteriormente de acordo com o seu cenário e veja o Protractor (animação 1) a todo vapor! 🤯
Ao final da execução, se tudo ocorreu da maneira esperada, resumidamente no console (figura 4), será exibido a descrição do caso de teste, seguido pela quantidade de testes e tempo de execução:
E falando em boas práticas… 🤓
É certo que o uso de boas práticas na codificação traz diversos benefícios, tanto que não ficarei abordando aqui sobre esse assunto e irei direto ao ponto! A seguir, deixo uma lista de práticas recomendadas por diversos autores contemporâneos do mundo e2e e que sempre que tenho alguma dúvida se estou seguindo o caminho certo, releio-os. Abaixo estão os quais levo como meus Dez Mandamentos E2E:
I. Não criarás testes E2E para funcionalidades que contemplam testes unitários;
II. Utilizarás apenas um arquivo de configuração;
III. Estruturarás e agruparás os testes de maneira que faça sentido ao projeto;
IV. Darás preferência aos localizadores de elementos do Protractor;
V. Evitarás a utilização de textos estáticos e Xpath’s para capturar elementos;
VI. Sempre farás o uso de PO’s — sempre mesmo, blz?;
VII. Declararás funções para operações que realizam mais de um passo. Por mais que seja um dos conceitos básicos de clean code, é válido ressaltar;
VIII. Criarás Wrappers quando houver elementos utilizados por diversos testes, que nada mais são do que um sinônimo de PO, porém, de maneira que esteja num escopo global;
IX. Restabelecerás o estado original da página que testada a cada it (caso de teste);
X. Criarás casos de testes totalmente independentes uns dos outros, caso contrário, muito em breve seus testes começarão a quebrar e você nem saberá o por quê!
Agora é sua vez! Inspecione os elementos web de sua aplicação e elabore novos testes. Com o tempo você, verá como é prático criá-los, além dos benefícios que testes bem elaborados podem conceder no decorrer da implementação de novas features em sua aplicação.
Obrigado por sua leitura até aqui! Espero que possamos nos reencontrar em breve em outras publicações. 🤘😎
