Nossa experiência com o Robot Framework em 6 meses...

Olááá robotizadores!!! Acho que muitos se perguntam: Por que Robot Framework? Por que o blog? Bom, vou contar a experiência que eu tive trabalhando  com ele durante esses últimos 6 meses e responder essas perguntas para vocês!!!! Chega mais...

01 - Minha experiência com testes automatizados

Antes do meu atual cargo, onde o foco são testes de APIs, eu trabalhei com o Test Complete automatizando testes de regressão e smoke testes de um legado Desktop. E só! Tinha conhecimento apenas de Delphi e C#, e para a automação no Test Complete usava Delphi. Já onde trabalho hoje, entrei para um time novo, recém criado, cujo o foco são integrações, então, surgiu a necessidade de automatizarmos nossas soluções de interoperabilidade, testes esses que eu só tinha uma experiência básica por ter realizado apenas alguns testes manuais um dia no trabalho anterior.

02 - O primeiro POC: FITNESSE

Nos foi sugerido o uso do FITNESSE, pois ele atende ao ATDD e já tinha sido usado com sucesso por um outro time. Maaas, o que não sabíamos era que esse time que obteve tal sucesso foi com testes WEB e não de APIs (ficamos sabendo tarde demais). A nossa POC então fracassou, eis os motivos:
- Instalaçãodo FITNESSE é custosa, principalmente para quem não tem experiência com Java (EU!).
- A fixture para testes de API REST do FITNESSE não suporta o template BDD.
- As bibliotecas de conferência de JSON são bem limitadas (alguns dos nossos JSON costumam ser enormes e a temos que fazer a conferência com comparações JSON x JSON e não item a item).
- Até hoje não consegui rodar ele por linha de comando, o que é necessário para rodar em container e CI (na documentação diz que é possível, mas até hoje não consegui).
- LOG ruim, pois não cria uma página avulsa, a página do próprio script de teste ficava gigante com os LOGs após a execução tornando difícil e custoso visualizar os erros.
- Forma de escrever em Wiki chatinha e nada lindo.
- Documentação fraca e "googlar" não ajudou muito, raríssimos são os artigos/blog sobre ele, e quando acha é um basicão apenas.

03 - A ideia do Robot Framework

Então tivemos que pensar em outro framework... Foi vendo um vídeo do QA Ninja Conference que conheci o Robot, e vi que era bem intuitivo, foi fácil entender o que o palestrante (em 01 horinha) mostrou e o core dele era Python. Aí acendeu uma luz, pois nosso time desenvolve em Python, ou seja, se eu usar um framework em Python, terei mais suporte do time, diferente do FITNESSE que era Java e apanhei por não conhecer bem o Java e suas manhas! Conversei então com o time e topamos fazer um segundo POC, só que agora com o Robot!

Dessa vez deu certo e conseguimos entregar toda a demanda de automação que surgiu, tanto de API quanto WEB e já com os cenários BDD. Sendo assim, efetivamos seu uso e já estamos há 6 meses com ele!!!

Apesar do blog, não sou nenhuma especialista em Robot (ainda), por isso ia anotando tudo que aprendia para lembrar/usar depois. Então, durante a POC, surgiu uma ideia: por que não compartilhar essas anotações? Surge então o nosso blog! Ele se tornou um tutorial para novos QAs que entram no time, um bloco de notas para mim e um material para a comunidade!! E está sendo super bacana compartilhar o Robot e torná-lo mais vísivel, pois, assim como nos solucionou um problema, pode solucionar para mais pessoas!

04 - Por que escolhemos o Robot Framework?

Os motivos da POC ter se tornado efetiva, resumidamente são:

- Por ser um framework genérico, conseguimos automatizar as soluções WEB junto com as de API.

- Foi fácil instalar, instalei o Python (que não é nada díficil) e rodei o comando 'pip install robotframework' e pronto!

- Foi fácil aprender e usá-lo, pois é mais intuitivo. Você escreve e implementa seus testes por keyword-driven (mais alto nível), o que facilita e muito quem não está acostumado com linguagens de programação. E olha que eu sei programar e reforço que é muito importante e válido um QA saber programar... Mas esse assunto fica para um outro post... Mas imagina quem está começando agora na área? Imagina aquele monte de QAs "antigos" que escolheram essa profissão por não gostar de programar? Imagina você (empresa) contratando urgentemente e não acha QAs experientes com automação, mas precisa pra ontem de automação no time para atingir as metas? Foi o que aconteceu com a gente! O Robot, no nosso caso, foi uma solução, pois rapidamente treinamos QAs com pouca experiência em automação e eles já começaram a produzir!

- A documentação é acessível e fácil de compreender. Tanto o Robot, quanto as libraries, vêm junto com uma boa documentação de keywords! O que tornou o item acima bem possível.

- Implantamos BDD sem nenhum esforço extra, bastou seguirmos o modelo de escrita das keywords em Gherkin.

- É possível gerar documentação a partir dos casos de teste escritos nele através do testdoc e publicar em documentações com o uso do Sphinx, por exemplo.

- Os LOGs e REPORTS que ele gera são suficientemente detalhados e organizados. São criados em .html a parte e com opções de customização.

- Fácil de rodar por linha de comando e a documentação sobre isso é bem disponível também.

- Você usa o editor ou uma IDE de preferência, desde que tenha plug-in, para escrever seus testes.

- É multiplataforma, roda no windows, linux, MAC. Inclusive nos nossos containers docker!

- Já precisei de recursos que não existiam em libraries prontas, rapidamente (15 minutos) criei o recurso em Python (com a ajuda dos nossos DEVs) e vinculei como library no Robot, problema solucionado!

- Comunidade gringa super ativa... e o motivo do blog existir também é termos uma comunidade BR, por que não?

- Não tivemos nenhum problema ou impedimento com ele até agora... Não sei compará-lo com outras ferramentas, dizer se ele é melhor ou pior que elas, tipo o Cucumber por exmeplo, pois não tive contato com elas. Sei que FITNESSE perde feio, as demais não sei opinar!

Bônus: Opinião de outro colega, de outro time, que também já usa o Robot Framework para testes WEB

No meu time WEB, o Robot Framework (RF) já foi a primeira opção sugerida pelo consultor e, como eu não conhecia e estava querendo tentar algo novo, resolvi experimentar. A POC deu super certo! Antes de ter contato com o RF, já tinha trabalhado com TestComplete e com Selenium Webdriver puro. O SW puro é muito difícil de usar e os testes de GUI ficam muito instáveis, pois é preciso implementar as condições de espera e mudanças de estado tudo na mão. Com o RF, fica tudo bem mais fácil. Ele já tem diversas funções de espera (wait until...) já padronizadas e, para os casos de não haver uma específica para o seu caso, pode usar o executor de JavaScript: daí é só escrever uma expressão JS que retorna um valor que o RF vai aguardar até que o valor fique igual ao que você espera! O log também é muito bom! É bem detalhado, facilitando bastante a identificação de onde o erro aconteceu.

Aqui automatizamos somente web/GUI e a biblioteca do Selenium do RF é muito completa e estável. Não tivemos problema algum com instabilidade que fosse relacionada à biblioteca ou ao RF.

Outra grande vantagem é a possibilidade de criar novas bibliotecas em python, que é uma linguagem muito prática e poderosa. A integração entre bibliotecas customizadas e padrão é tão suave que nem percebemos a diferença. Além disso, o RF é open source, então se você criar uma biblioteca que acredita que poderá ajudar outras pessoas, pode publicá-la e ajudar a comunidade do RF crescer ainda mais.

O RF também facilita a organização, e conseguimos implementar o padrão de PageObjects sem nenhum problema. Também oferece suporte a tags, para organizar a execução dos testes!

O único ponto fraco do RF, mas que eu acho que é mais uma questão de tradeoff do que problema de implementação (por tentar usar uma linguagem mais natural possível), é quando precisamos fazer algumas estruturas mais complexas um pouco, como utilizar laços FOR. Nesse ponto, não acho a sintaxe tão intuitiva, mas, no pior dos casos, podemos simplesmente implementar essa lógica em python e pronto!

Conclusão

Bom pessoal esse foi o nosso ponto de vista, tanto eu quanto meu colega estamos a 6 meses trabalhando efetivamente com o RF! Não estou afirmando que ele é solução para todos, até por que o que funciona pra mim pode não funcionar para você, mas achei legal compartilhar esses cases de sucesso e dar a chance de pessoas conhecê-lo e quem sabe experimentá-lo também!!!

E vocês?? Já experimentaram o Robot nem que seja por curiosidade?? Conta pra gente como foi a experiência. E, se alguém já teve algum problema/impedimento, compartilha também!!!! Abraço e até a próxima robotizadores!!! NEW: veja a continuação desse post 2 anos após: Nossa experiência com o Robot Framework em 2 anos e 6 meses...