Ferramentas de testes de aceitação: uma odisséia.
Tive o privilégio de começar um projeto desde a sua primeira linha de código e, como consequência, participar de grande parte, senão todas, as suas decisões técnicas. Que tecnologia utilizaremos para a web? E para o back-end? Qual estrutura de CI melhor se enquadra no nosso contexto?
Qual a melhor ferramenta para realizarmos teste de aceitação?
Existe um mar de ferramentas com este propósito por aí. Ferramentas de testes de mais alto nível geralmente trazem consigo a característica de serem agnósticas a linguagem de programação do resto do projeto. Existem ferramentas das mais sólidas às mais hipsters, o que torna impossível definir uma bala de prata para todo e qualquer projeto.
O que são testes de aceitação?
Existem vários níveis de testes, quando pensamos em uma aplicação. Cada teste tem um propósito diferente, e eles geralmente são separados não só por seu propósito, mas também por seu custo em ser executado.
Uma boa forma de visualizar isto é através da pirâmide de testes:
Quando falamos de testes de aceitação, na imagem, estamos querendo corresponder à camada de UI, ou Interface do Usuário. A idéia de um teste de aceitação, também chamado de teste end-to-end, é simular um fluxo de execução que um usuário realizaria, para avaliar se o funcionamento é como o esperado.
Estes são os testes automatizados mais custosos na pirâmide de testes, então decidir quais fluxos são importantes de serem testados neste nível é essencial.
Como decidir entre as ferramentas existentes?
A próxima melhor solução, então, é ser capaz de definir atributos para cada ferramenta que parece ter potencial, e escolher uma ferramenta de acordo com cada contexto. As características que decidi utilizar para avaliá-las — e os motivos pelos quais as escolhi como fatores importantes no processo decisório — você pode entender melhor neste post.
Conheça os candidatos:
(dados coletados em outubro/2017)
O Capybara é uma ferramenta de testes agnóstica de navegadores que roda seus drivers através do Selenium.
1. É uma ferramenta de código aberto?
Sim! Acesse o repositório do github aqui.
2. O quão nova é esta ferramenta?
Existe desde 2009, e é uma ferramenta bastante difundida quando se falam em testes de aceitação.
3. Quantas issues existem abertas hoje?
Cinco abertas. 1174 fechadas. Todas as abertas têm comentários, o que indica que existe uma comunidade forte.
4. Qual a frequência de atualizações da ferramenta?
Você pode verificar os releases do Capybara aqui. A ferramenta é frequentemente atualizada, dando mais motivos pra acreditar na comunidade forte e participativa no seu desenvolvimento.
5. Qual o tamanho da comunidade?
245 watches, 8026 stars, 1168 forks. 228 contributors. Parece um veredito final: muita gente usa e colabora com o Capybara.
6. O quão complexo é preparar o terreno para a aplicação?
Pode ser porque foi a primeira ferramenta que testei, mas entender como alinhar os astros para rodar os testes de aceitação foi particularmente doloroso. Toda a documentação da aplicação está dentro do readme do GitHub, mas não há indícios de que preocupação em auxiliar os novatos a subir a aplicação seja algo prioritário.
Depois de ser capaz de executar os testes pela primeira vez, tudo fica mais simples, mas eu já tinha desenvolvido um desgosto pela ferramenta depois de tanto trabalho.
7. O quão complexo é escrever um teste simples?
Os testes são escritos em Ruby, e a ferramenta te permite escolher o seu framework de testes preferido. (minitest, RSpec, testunit). Se você já está acostumado com a linguagem e pelo menos um destes frameworks, você provavelmente não terá dificuldades em entender como as coisas funcionam.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
Por possuir uma comunidade bastante grande, existem vários posts e plugins para rodar os testes nas estruturas de CI mais conhecidas.
9. Qual a qualidade do retorno que a ferramenta dá?
A mesma qualidade do retorno das ferramentas de teste em Ruby — que eu, particularmente, não gosto, mas se floats your boat…
10. O que torna esta ferramenta especial?
Pelo que eu aprendi durante estes estudos, Capybara é uma das ferramentas mais conhecidas, difundidas e sólidas quando o assunto são testes de aceitação. Se você estiver inclinado a tomar uma decisão mais conservadora, e seu time estiver confortável com Ruby, Capybara parece ser a melhor decisão.
Para rodar numa estrutura de CI, ela é geralmente integrada com PhantomJS — e, se você não sabia, ele está sendo descontinuado. Mas a ferramenta já dá suporte a utilizar o Chrome Headless, seu oficial substituto.
Chromeless
O Chromeless é uma ferramenta de testes cujo princípio é executar seus testes dentro do Google Chrome, utilizando o Chrome Headless. A proposta é diminuir o tempo de feedback para testes de mais alto nível.
1. É uma ferramenta de código aberto?
Sim! Acesse o repositório do GitHub aqui.
2. O quão nova é esta ferramenta?
A versão 1.0 foi lançada dia 26 de Julho de 2017, o que a torna uma ferramenta bem nova.
3. Quantas issues existem abertas hoje?
133 issues abertas. 96 fechadas. O fluxo de issues parece ser extremamente alto, o que indica que a ferramenta está começando a ser mais utilizada pela comunidade. O grupo que dá suporte parece estar fazendo um bom trabalho em analisar e entender os problemas que vêm aparecendo.
4. Qual a frequência de atualizações da ferramenta?
Houveram três releases em agosto, e nenhum em Setembro. A última modificação no código foi há um mês atrás, mas há 24 pull requests abertos.
5. Qual o tamanho da comunidade?
204 watches, 10637 stars, 355 forks. 25 contributors. Por ser nova, ainda não há tantos contribuidores, mas o Chromeless já possui mais estrelas que o Capybara, mesmo com tão pouco tempo de vida.
6. O quão complexo é preparar o terreno para a aplicação?
O Chromeless é escrito em Node.js e houve uma sensação muito grande de plug-and-play. A sua documentação no repositório é mais que suficiente para entender como utilizá-lo, e o intervalo entre saber o que significa Chromeless e rodar um teste de exemplo foi de dez minutos.
7. O quão complexo é escrever um teste simples?
O Chromeless pareceu a mais intuitiva dentre todas as ferramentas de teste que eu experimentei, acredito que por ter mais facilidade com JavaScript. Escrever um teste próprio foi extremamente rápido — também questão de minutos.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
Talvez por ser ainda muito novo, não há nenhuma menção sobre Continuous Integration em sua documentação, e também não há muitos posts tratando sobre isso, mas acredito que não possa ser muito difícil, já que apenas exige que existam o node, o npm e o chrome instalados na máquina.
9. Qual a qualidade do retorno que a ferramenta dá?
O retorno não é nada definido. Se há algum erro, ele é retornado no console. Se tudo ocorre com sucesso, não há feedback algum.
A ferramenta te permite tirar screenshots da tela para validar todos os passos.
10. O que torna esta ferramenta especial?
Acredito que a principal motivação para a existência do Chromeless é livrar-se do padrão de utilização do Selenium e do PhantomJS para testes que integram com navegadores. Isso pode ser um ponto negativo, caso você precise testar sua aplicação em diversos navegadores diferentes.
O Cypress é uma ferramenta que tem como princípio não precisar dos drivers de navegador mais comuns para rodar testes de mais alto nível. Atualmente ela está em beta.
1. É uma ferramenta de código aberto?
Sim! Acesse o repositório no GitHub aqui.
2. O quão nova é esta ferramenta?
Ela foi majoritariamente escrita em 2015, mas seu lançamento foi feito somente em Junho, Julho de 2017, em fase de desenvolvimento.
3. Quantas issues existem abertas hoje?
245 issues abertas. 464 issues fechadas. Parece existir um trabalho bem forte de suporte no time que desenvolve a ferramenta, mas é um time relativamente pequeno.
4. Qual a frequência de atualizações da ferramenta?
Após o primeiro release, não houve mais nenhum release oficial.
5. Qual o tamanho da comunidade?
52 watches, 1109 stars, 14 forks. 5 contributors. Parece uma ferramenta relativamente desconhecida.
6. O quão complexo é preparar o terreno para a aplicação?
Também tive uma sensação muito forte de plug-and-play. Basicamente instalei o pacote npm e tudo já começou a funcionar.
7. O quão complexo é escrever um teste simples?
Também não tive problemas em escrever um teste simples. Fiquei com a impressão de que a curva de dificuldade é exponencial quando relacionada à complexidade do teste, mas não tenho exemplos para explicar isso. Foi só uma impressão.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
A ferramenta se importou em trazer guias e plugins para integrá-la às principais ferramentas de CI existentes, em sua documentação.
9. Qual a qualidade do retorno que a ferramenta dá?
Sem dúvida alguma, o feedback visual é a melhor qualidade desta ferramenta, e ela ganha de lavada de qualquer outra. Ela é acompanhada de uma interface visual que roda os testes e mostra o passo-a-passo do teste criado, verificando se estes passos falharam ou passaram. A documentação traz um exemplo deste feedback em um GIF que você pode ver aqui.
10. O que torna esta ferramenta especial?
Acredito que a ferramenta foi idealizada também em uma época onde o Selenium era a única alternativa viável para testes em navegadores. Acredito que ela evoluiu numa direção muito diferente das outras ferramentas, se preocupando com feedback visual.
Mais uma ferramenta que usa Selenium, mas com código em JavaScript, a tornando agnóstica de navegadores. É interessante por parecer escalar de uma forma saudável em relação a complexidade de cenários.
1. É uma ferramenta de código aberto?
Sim! Veja sua página do GitHub aqui.
2. O quão nova é esta ferramenta?
20 de Julho de 2014 foi a data da primeira versão da ferramenta. Ela ainda não se encontra em uma versão oficialmente fora do beta.
3. Quantas issues existem abertas hoje?
252 issues abertas. 1071 issues fechadas. A frequência de issues dá a entender que é uma ferramenta que está sendo bastante utilizada atualmente.
4. Qual a frequência de atualizações da ferramenta?
Desde seu primeiro lançamento, já houveram outros 126. A frequência parece estar atualmente em um lançamento a cada dois meses.
5. Qual o tamanho da comunidade?
256 watches, 7246 stars, 649 forks. 60 contributors.
6. O quão complexo é preparar o terreno para a aplicação?
O NightWatch também deu um pouco de dor de cabeça. Ele tem algumas configurações básicas, e exige que você manualmente rode o driver do Selenium.
7. O quão complexo é escrever um teste simples?
O NightWatch me passou a sensação contrária ao Cypress. No melhor sentido: não é tão fácil testar um exemplo simples, mas também não é tão difícil testar um exemplo mais complexo.
Ele também é um dos que mais se parecem com os outros tipos de testes, que estamos mais acostumados. Tem nome, assertions e o feedback no console é como o das outras suites de teste unitários e de integração.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
Como é um projeto com uma comunidade considerável, existem vários posts e plugins para integrar com a escolha de CI que você mais curte.
9. Qual a qualidade do retorno que a ferramenta dá?
O que me chamou a atenção e destacou o NightWatch é que ele trata testes de aceitação como qualquer outro tipo de testes. Os feedbacks de erros parecem ser bem assertivos, facilitando suas correções.
10. O que torna esta ferramenta especial?
Parece ser uma ferramenta com bastante aceitação, tempo considerável, e uma qualidade bacana. Se o Capybara é uma escolha conservadora e o Cypress é uma escolha hipster, o NightWatch é o meio do caminho.
Puppeteer
Porque é claro que a Google teria uma ferramenta própria. Mas não, não é Puppet. É puppeteer.
1. É uma ferramenta de código aberto?
Sim! Repositório do GitHub aqui.
2. O quão nova é esta ferramenta?
O Puppeteer nasceu dia 16 de agosto de 2017.
3. Quantas issues existem abertas hoje?
127 abertas, 448 fechadas.
4. Qual a frequência de atualizações da ferramenta?
Desde 16 de agosto já houveram outras 4 atualizações. Existem vários pull requests já integrados e poucos abertos, o que dá a entender que é uma ferramenta em constante atualização e aperfeiçoamento.
5. Qual o tamanho da comunidade?
351 watches, 15265 stars, 583 forks. 47 contributors. Parece que temos um campeão de estrelas.
6. O quão complexo é preparar o terreno para a aplicação?
Sensação de plug-and-play. Após instalar a biblioteca, já é possível rodar os testes.
7. O quão complexo é escrever um teste simples?
Bem simples. Existe uma noção muito interessante de focus na hora de escrever o teste. Enquanto em todas as outras ferramentas você seleciona algo para clicar, ou alterar, numa mesma linha de código, o Puppeteer pede que você foque em um elemento antes de interagir com ele.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
Não se fala muito sobre isso na sua documentação, mas pelo aspecto plug-and-play, acredito que não seja lá muito complexo.
9. Qual a qualidade do retorno que a ferramenta dá?
Achei isso extremamente curioso: o Puppeteer não se preocupa em dar um feedback para o usuário. Ele te ensina a pegar os logs de debug do próprio node e te encoraja a escrever os logs de teste por você mesmo.
10. O que torna esta ferramenta especial?
Suporte ao Chrome headless, tem um time na Google que mexe, por parte do tempo, na ferramenta, parece ter uma expectativa muito grande à sua volta. Permite tirar screenshots e gerar PDFs.
Mais uma alternativa a testes de aceitação em Ruby. Usando Selenium.
1. É uma ferramenta de código aberto?
Sim! Acesse o repositório no GitHub aqui.
2. O quão nova é esta ferramenta?
O Watir existe desde 16 de Junho de 2010.
3. Quantas issues existem abertas hoje?
Existem 25 issues abertas, e 427 issues fechadas.
4. Qual a frequência de atualizações da ferramenta?
A última atualização foi há 28 dias atrás, e o último commit há 21 dias, ou seja, parece ter uma comunidade ainda bastante ativa.
5. Qual o tamanho da comunidade?
79 watches, 971 stars, 177 forks. 33 contributors.
6. O quão complexo é preparar o terreno para a aplicação?
Eu tive as mesmas dificuldades que tive com o Capybara, para ser honesto. Os exemplos na documentação falhavam, e as duas ferramentas parecem existir para serem integradas com o Ruby on Rails.
7. O quão complexo é escrever um teste simples?
Tive mais problemas para rodar um teste simples do que com qualquer outra ferramenta, mas depois de escrito, achei bem fácil de ler e entender do que se tratava. Ele também utiliza as habilidades de teste dos principais frameworks de teste em Ruby.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
Não há muitos posts explicando como adicioná-lo a uma estrutura de CI, mas acredito que seja mais difícil de integrar que o Capybara.
9. Qual a qualidade do retorno que a ferramenta dá?
Os testes, assim como o Capybara, rodam através do framework de testes escolhido, então o feedback é o mesmo.
10. O que torna esta ferramenta especial?
Honestamente? A minha experiência foi muito parecida com a do Capybara. Acredito que a escolha esteja mais relacionada a ter uma ferramenta que ainda se encontra em estado de evolução, enquanto o Capybara já está num momento mais estável. O approach dos testes também é um pouco diferente, e a documentação é bem rica.
WebdriverIO
Uma opção de Framework em Node.js utilizando Selenium.
1. É uma ferramenta de código aberto?
Sim! O repositório no GitHub está aqui.
2. O quão nova é esta ferramenta?
O WebdriverIO nasceu dia 17 de maio de 2012.
3. Quantas issues existem abertas hoje?
Existem 91 issues abertas. 1601 issues fechadas.
4. Qual a frequência de atualizações da ferramenta?
Existem ciclos de vários lançamentos por mês, e alguns meses com poucos lançamentos. Mas os commits são mais frequentes.
5. Qual o tamanho da comunidade?
161 watches, 3389 stars, 900 forks. 264 contributors. Troféu de campeão em número de contribuidores diferentes.
6. O quão complexo é preparar o terreno para a aplicação?
De todas as ferramentas em Node.js, o WebdriverIO foi o mais complicado. Ele possui arquivo de configurações e exige que você rode manualmente o Selenium.
7. O quão complexo é escrever um teste simples?
Também achei bem intuitivo escrever um teste simples. Ele também te dá a visão geral de um caso de teste como os de níveis mais baixos.
8. Quão difícil é integrar a ferramenta a uma estrutura de CI?
O npm instala um programa que te permite configurar em que ambiente você pretende rodar os testes, de forma que facilita o preenchimento do arquivo de configurações e te direciona, caso queira rodá-lo em uma estrutura de CI.
9. Qual a qualidade do retorno que a ferramenta dá?
Quase nenhum retorno. O formato é muito parecido com o retorno dos testes do Capybara e do Watir.
10. O que torna esta ferramenta especial?
Das ferramentas em Node.js, o WebdriverIO é a única que utiliza o Selenium. Portanto, se você precisa realizar testes em diferentes navegadores, parece uma boa opção.
Ele também é a opção em Node.js mais madura, o que a torna uma escolha mais conservadora e segura.
Mas e Cucumber? RobotFramework? Serenity? E x?
Como citado acima, existem diversas ferramentas cujo propósito é realizar testes automatizados em navegadores. Por estar realizando esta avaliação especificamente para meu projeto, acabei decidindo por não avaliá-las.
Se você já as utilizou e avaliou, e quiser adicioná-las aqui, por favor, sinta-se livre para colaborar.
Enough talk, show me de code!
Se você tem interesse em visualizar exemplos extremamente simples de utilização das ferramentas acima, você pode dar uma olhada neste repositório do GitHub.
Conclusão
Não existe uma forma fácil de decidir qual ferramenta escolher para utilizar em um projeto. Cada uma tem uma proposta única, e cada pessoa e time se adaptarão melhor a uma ferramenta diferente.
Espero que estes pontos sejam o suficiente para te ajudar a decidir qual ferramenta parece valer mais a pena adotar no seu projeto.
Se houverem dúvidas, sugestões, correções ou melhorias, não hesite em me contatar.
