Como quaisquer outros, testes automatizados também são sistemas, e devem ser desenvolvidos utilizando de boas práticas de arquitetura de software, de escrita de código, de padrões de desenvolvimento, e de manutenibilidade.
Ao iniciar o desenvolvimento de uma aplicação web pelos testes, já dá pra se dizer que começou bem! Mas mesmo os testes, ao longo do tempo precisam ser organizados e refatorados, para que se seja mais fácil encontrar os artefatos quando a aplicação começar a crescer; para que haja divisão de responsabilidades; por questões de reuso de código; para entendimento padronizado de questões referentes a sintaxe e padrões; e para que a curva de aprendizado do sotware seja curta a qualquer novo desenvolvedor que venha a fazer parte do time ou mesmo dar manutenção (quando necessário) ao sistema.
Em minha experiência no desenvolvimento de testes funcionais de regressão para aplicações Angular JS (web e mobile) com uso do Protractor, aos poucos comecei a perceber a necessidade da divisão dos testes em mais arquivos, separados por funcionalidades ou telas, para facilitar na execução de testes de uma funcionalidade específica, e por questões de organização; também evoluí sobre a importância dos helpers, para facilitar a reutilização de código em testes que acabam necessitando de um fluxo que se repete, e então faz uma ação e/ou validação diferente, ou seja, já que algumas coisas vão se repetir ao longo dos testes, o melhor é que funções sejam criadas e quando necessárias, sejam só chamadas, facilmente; outro ponto é a importância da revisão de código, para que o que foi desenvolvido seja analisado por outra perspectiva e que o feedback desta revisão agregue valor ao resultado final entregue, seja na correção de um falso positivo, ou mesmo na sugestão de outra abordagem (pensando em usabilidade, por exemplo) para a próxima versão de certa funcionalidade.
Quando iniciei com o Protractor, aprendi que existem dois arquivos primordiais, o spec.js, com os testes propriamente ditos; e o conf.js, com informações relacionadas a onde o web-driver estará rodando, qual arquivo de testes deve ser utilizado, em qual ou quais browsers serão executados os testes, dentre outros.
Porém, logo que mais de uma funcionalidade foi desenvolvida, já foi interessante quebrar os testes em arquivos *.spec.js, separando-os pelas funcionalidades. Ex.: login.spec.js, cadastro-de-cliente.spec.js, logout.spec.js. Com isto, quando necessário rodar testes de uma funcionalidade específica, eu podia informar ao arquivo conf.js, qual funcionalidade específica queria testar, ou mesmo informar na linha de comando ao executar o protractor conf.js, qual arquivo específico queria utilizar, como mostrado abaixo.
protractor conf.js --specs login.spec.js
Como comentei mais acima, na escrita dos testes comecei a notar que para todo o teste eu precisava antes de um login bem sucedido, ou então, que eu sempre tinha que acessar certa tela, e antes de começar a interagir com ela, verificar que alguns elementos estavam presentes. E comecei a notar que eu estava duplicando código.
Neste momento, foi a hora de parar e refatorar, e só parar quando o refactor do testes continuava passando, como era antes dele. E um bom modo de rafatorar, foi a criação dos helpers.js, os quais faziam o trabalho repetitivo, e para eu fazer um login com sucesso, por exemplo, eu podia somente escrever o código abaixo.
loginHelper.successfullyLogin();
E para que a função acima estivesse disponíveis em meu arquivo spec.js, o qual iria precisar de um ou mais logins bem sucedidos, bastava adicionar a seguinte linha no início de meu arquivo de testes (*.spec.js)
var loginHelper = require('../helpers/login.helper');
Com a criação dos helpers, começou a ficar cada vez mais fácil a escrita de testes realmente end to end, pois eu tinha um helper para o login, um helper para o cadastro de clientes, e um helper para o logout, podendo simular este fluxo (login, cadastro de cliente e logout) com somente três linhas de código.
loginHelper.successfullyLogin();
clientHelper.addClient('João');
logoutHelper.logout();
E então pensar em cenários variados, e daí iniciar um novo refactoring caso necessário, para atender a esta nova demanda; a criação de novos helpers; e a evolução dos testes.
Vale lembrar que sempre há espaço para melhorias e que são nestes momentos que sinto que evoluo como profissional, pois tenho que sair da zona de conforto, aprender novas técnicas, novas ferramentas, novas tecnologias, e me desafiar a fazer melhor. Portanto, como coloquei no título, este post é uma reflexão, e um pouco de código, e em breve pretendo fazer a continuação do post Testando aplicações AngularJS com Protractor, para exemplificar algo do que brevemente comentei aqui, e algo mais.
Aguardo teu feedback, e espero que tenha gostado! =D
TALKING ABOUT TESTING 