Quando estamos desenvolvendo uma automação de testes, precisamos executá-la diversas vezes para validar alguma lógica do código ou para saber se o que foi escrito está realmente testando a funcionalidade do jeito adequado. Mas isso pode gastar muito do nosso tempo, pois serão necessárias muitas repetições até chegar ao trecho da execução. Imagine a seguinte situação:

Uma funcionalidade simples, mas que tenha três passos. O teste escrito inicialmente para ela funciona bem no começo, mas no meio do script ele não se comporta como deveria e acaba quebrando. Nesse caso você teria que fazer o ajuste e rodar novamente o teste todo, mas isso pode gastar muito tempo, pois a cada novo ajuste você precisa rodar todos os outros passos anteriores para validar apenas um único ponto do código que está no meio ou no final dele, por exemplo.

A solução para isso é ter um “breakpoint” no meio da automação, onde você consegue interagir com o software e validar seu código/lógica em tempo real e encontrar o melhor jeito de escrever seu teste.

Na linguagem Ruby temos a gem Pry que faz exatamente isso.

Pry é uma gem que podemos usar para incluir esse ponto de debug no meio da automação, ou seja, no caso que citei acima, basta incluir o Pry no segundo passo e enquanto a automação está pausada, podemos inserir comandos no terminal e ver quais se comportam melhor nessa parte do software.

Pry é uma alternativa poderosa para o IRB, padrão do terminal Ruby. Possui destaque de sintaxe, uma arquitetura de plugin flexível, invocação de tempo de execução e navegação de fontes e documentação.

Como toda gem em Ruby, é necessário primeiro fazer a sua instalação. Para isso, use o comando abaixo:

gem install pry

Além disso, temos que adicionar ao arquivo Gemfile do projeto essa nova dependência. Abaixo, existe um exemplo. Este é o arquivo que uso em meu projeto.

Dentro do projeto precisamos também fazer um require para poder usar os recursos do Pry. Minha automação de testes foi feita com o framework Appium, e como tenho um arquivo de configuração centralizado, deixei o require dentro dele.

O próximo passo é identificar onde o teste está quebrando. Se você estiver usando o Cucumber, isso fica bem mais fácil. Para exemplificar, vou usar uma funcionalidade básica: fazer um login no sistema, como já foi citado. Ele tem três passos.

No exemplo, a automação está conseguindo acessar a plataforma e digitar o nome do usuário e a senha, mas ela está quebrando no momento de clicar no botão para efetivar o login.

Ou seja, o passo “quando efetuo o login com credenciais válidas” não está funcionando direito. Para ajudar na correção, temos que usar o Pry e, para isso, temos que ir na automação e inserir o comando “binding.pry” antes do problema. Esse comando vai ser responsável pelo momento em que o debug vai ser acionado.

Rodei a automação com o Pry e vou descrever abaixo as etapas que usei:

• [0] Após rodar a automação pelo terminal, o teste percorre os passos anteriores e entra em modo debug, aguardando a nossa interação por meio de comandos. Na imagem, conseguimos ver o trecho exato onde a automação está parada;
• [1] usei novamente o comando find_element(id: ‘button’).click e a automação retornou ao erro que já foi identificado;
• [2] alterei a estratégia de localização do elemento e agora, ao invés de buscar pelo id, estou usando o tag_name. Veja que na mensagem abaixo é retornado um identificador do elemento em verde;
• [3], [4] e [5] como agora já encontrei o elemento, estou usando outros métodos de interação e o retorno de cada ação é exibido abaixo:

.displayed? retorna true
.text retorna “Login”
.name retorna ” ”

• [6] usei o método .click no elemento e com esse comando a automação passa a funcionar do jeito que esperamos;
• [7] digitei o comando exit, isso faz com que a automação saia do debug do Pry e volte a executar o resto do seu fluxo.

Depois que toda a automação é finalizada, o report do cucumber é gerado normalmente.

Agora que sabemos qual comando nos atende, basta remover o binding.pry da automação e arrumar o passo com o comando que achamos no momento do debug.

Usando essa estratégia, conseguimos economizar bastante tempo, pois não temos que rodar a automação inteira toda a vez que precisamos saber o melhor jeito de interagir com o software. E creio que isso é um ganho importante durante o projeto.

Lembrando que essa gem também serve para debugar qualquer código Ruby, mas o foco desse artigo é na parte de testes.

Se você usa outra linguagem em seus testes ou debuga de outro jeito, por favor, comente como faz isso aqui no artigo, pois assim a postagem não fica presa em Ruby, apenas. Para JavaScript, vi que existe o PryJS, mas não cheguei a explorá-lo ainda.

Subi para o Github (manda PR) o projeto usado no artigo e você pode usá-lo para brincar com essa Gem.

Bons testes!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/03/26/debugando-seus-testes-usando-a-gem-pry/