Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Utilizando Page Object para organizar os testes com Protractor

Quando falamos sobre padrão de projeto para escrita de testes, sempre ouvimos falar em Page Object. Mas o que é isso?

Na interface do usuário, existem elementos com os quais seus testes interagem. Um page object simplesmente modela esses objetos dentro do código de teste. Isso reduz a quantidade de código duplicado e significa que se a interface muda, a correção precisa ser aplicada em um só lugar.

A page object wraps an HTML page, or fragment, with an application-specific API, allowing you to manipulate page elements without digging around in the HTML.

https://martinfowler.com/bliki/PageObject.html

O que isso quer dizer, afinal?

Devemos entender três pontos importantes quando estamos trabalhando com Page Object:

  • O acesso aos elementos da página passa a ser de responsabilidade de um Page Object e este deve prover métodos para que possamos realizar ações sobre esses elementos. Esse é o conceito de encapsulamento.
  • Quando estamos escrevendo o teste, não deveríamos nos importar se um elemento é acessado através do seu id, ou localizado pela sua class, por exemplo. Suponhamos que se trata to preenchimento de um formulário, deveríamos apenas informar o valor para os campos e aguardar a resposta de sucesso ou não no envio dos dados. Do ponto de vista do teste, detalhes da implementação do formulário não deveriam ser relevantes. Isso é chamado de abstração.
  • Ao teste cabe a preparação dos dados, a execução do script e a verificação dos resultados obtidos. O código do teste se ocupa do AAA (Act, Arrange e Assert) e o Page Object interage diretamente com a API do WebDriver para interagir com os elementos e realizar as ações na página. Essa distinção é chamada de separação de responsabilidades.

Let’s do magic!

Temos aqui uma spec que realiza três testes no site da API do AngularJs.

Podemos observar que tudo está em um arquivo só, desde a declaração dos elementos que devem ser buscados, até as ações e as verificações. Não há encapsulamento, abstração ou separação de responsabilidades no código da forma que foi feito.

Para refatorar o código, em primeiro lugar, devemos pensar quais pages devem ser criadas. Da forma como fiz, criei uma pasta no projeto para colocar três pages que estão relacionadas ao contexto do teste:

Pages criadas no projeto

Em seguida, levei o encapsulamento para as pages, declarando os elementos de forma pública para que possam ser utilizados na spec, bem como a função visit que acessa a página da API do AngularJs.

A page criada é exportada para que possa ser instanciada na spec.

apiPage.po.js

ngBindPage.po.js

textareaPage.po.js

A partir da criação das pages, a spec foi refatorada, importando as pages criadas e instanciando dentro do describe para poder chamar seus elementos e métodos públicos.

Pode-se observar que as duplicidades de código foram removidas, exceto os expects. Manter os expects na spec é uma boa prática, visto que a verificação é de responsabilidade do teste e não deve ser levada para as pages.

O projeto utilizado como exemplo pode ser baixado na minha página no GitHub.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.