Deixando testes automatizados mais organizados utilizando o conceito Page Object

Postado 13 de abril de 2017

Na Youse, quando começamos a formar o chapter de qualidade com os QAs, tínhamos em mente que trabalharíamos investindo em testes automatizados. Por essa razão resolvi escrever esse post pra compartilhar um pouquinho sobre algo que discutimos bastante: Page Object.

Levamos em consideração duas grandes premissas ao iniciarmos nossas discussões. A primeira é que um teste automatizado é formado por um conjunto de códigos que executam alguma ação, certo? E, com base na certeza da engenharia de software, código escrito é aquele que um dia vai mudar. Por esse motivo queríamos desenvolvê-los de um jeito que as futuras manutenções fossem mais fáceis.

Por que usar Page Object?

O Page Object é um design pattern que nos ajuda a organizar melhor nosso código. No início parece bem trabalhoso, por conta da quantidade de testes a serem escritos e pela ausência de objeto de página, porém, quanto mais escrevemos, mais benefícios são observados. Na organização, ele deixa o código do teste mais fácil de manipular na hora de realizar a manutenção, sem afetar outros pontos.

Como funciona?

Nos testes de aceitação, ele funciona como uma interface dos elementos HTML de uma página e diminui a responsabilidade do código de teste, deixando somente a ação do que testar, excluindo a preocupação em como realizar as ações e acessar aos elementos.

Exemplo 1: Login sem o uso de Page Object:

Screen Shot 2017-04-10 at 17.44.10

 

A maior desvantagem em não utilizar o Page Object, conforme exemplo acima, é que se em algum momento do desenvolvimento o id do elemento e-mail for alterado, o custo da manutenção se inicia.

Você pode pensar: “ah, simples: vou ter que alterar fill_in(‘email’)”. Sim, está correto, porém a alteração será necessária nos dois métodos. Imagine o quanto pode ser custoso se a classe tiver diversos cenários com esse elemento.  

Exemplo 2: Uso de Page Object na tela de login:

Screen Shot 2017-04-10 at 17.38.36

Screen Shot 2017-04-10 at 17.39.00

O benefício do exemplo acima é a abstração das ações da página para dentro do Page, respeitando um dos conceitos principais do Page Object, que é separar essa responsabilidade do código de teste. Ele não precisa saber como um elemento é mapeado (ex.: por id, name, css, xpath) e a classe de teste deve conter somente o que sem quer testar.

Ainda é possível enxergar algumas melhorias a serem feitas nesse exemplo. Pensando em um caso com mais cenários, teríamos mais testes e todos repetirão as ações de fazer o login (ex: preencher os campos e-mail, senha e clicar no botão login). Esse aprimoramento pode ser feito com o uso de uma gem chamada SitePrism, normalmente muito utilizada no desenvolvimento de testes de aceitação com Capybara. Ela fornece uma DSL de Page Obejct que deixa seu código simples e com uma excelente semântica.

Exemplo 3: Melhoria com o uso de SitePrism no Page Object na tela de login:

Screen Shot 2017-04-10 at 17.40.03

Fica nítido o quanto a semântica é melhorada com o uso do SitePrism. No primeiro bloco da classe temos mapeados todos os elementos que pertencem à página e não precisamos mais criar vários métodos com as ações de cada elemento, pelo fato do SitePrism ser uma DSL de Page Object para se trabalhar com Capybara. Com isso ele contribui com alguns métodos nativos como demonstrado no exemplo acima (.set, .click e .text) e outra novidade desse exemplo foi a criação do método login e do método check_message, o que vai deixar nosso código de teste mais limpo e objetivo. Observe:

Screen Shot 2017-04-10 at 17.40.47

Considerando que, nesse momento, precisamos alterar algum id de qualquer elemento da página, o custo com manutenção será baixíssimo, pois só seria necessário alterar uma linha de código, não sendo preciso quebrar o cenário de testes. Neste caso, a única preocupação que poderia existir seria a criação de mais cenários que envolvessem login. Desta maneira posso criar mais cenários de testes de login e me preocupar apenas com os parâmetros que passarei para o teste e a mensagem que espero.

Duas principais vantagens ao utilizar o Page Object são:

Encapsulamento: o acesso a elementos da página fica encapsulado dentro do Page Object.

Abstração: no momento de fazer o login, em um formulário tipo usuário/senha, o código de teste deve ser indiferente, pois preenchimento dos campos é feito por meio de um findElement(By.name(“”)) ou findElement(By.id(“”)). O código simplesmente deveria informar o usuário/senha e esperar que a autenticação seja feita com sucesso ou não.

O que acharam? A primeira impressão que tive quando comecei a estudar esse Pattern e gem foi de uma felicidade sem tamanho, porque as manutenções no projeto de testes automatizados ficaram muito mais fáceis e a organização do código ficou muito mais limpa. 

Para deixar ainda mais claro o benefício de usar Page Object e SitePrism, pense no seguinte: você trabalha em um time de desenvolvimento e conseguiu mapear 100% dos possíveis cenários de testes, automatizando-os quase na totalidade. Então você é convidado a participar de um novo projeto. Como seus trabalhos estão organizados,  qualquer pessoa do time consegue realizar as manutenções necessárias sem muita dificuldade. É muito importante deixar um legado positivo, para que pessoas possam dar continuidade nos seus ideais.  


Por: Adriano Fukuda