Há pouco mais de um ano, experimentei o Robot Framework. Durante minha participação em um projeto de grande escala, experimentei duas abordagens diferentes para testar a automação com esta ferramenta: escrever testes em um DSL Robot Framework puro e trabalhar em conjunto com o Python. Se o primeiro caminho tem um limite de entrada baixo, o segundo, na minha opinião, é mais conveniente do ponto de vista do suporte a grandes projetos. Embora não haja diferença fundamental entre as abordagens. De uma forma ou de outra, tudo se resume a encontrar bibliotecas.
No entanto, vale a pena falar sobre os recursos das abordagens.
Quem é o robô e com o que ele come
Provavelmente vale a pena começar com a introdução desta ferramenta poderosa.
O Robot Framework é um framework para testes orientados por palavras-chave. É usado para automatizar testes de aceitação e ATDD (abordagem de desenvolvimento através de testes de aceitação). Este sistema possui uma sintaxe de dados de teste fácil de usar e permite automatizar testes usando palavras-chave. Além disso, o Robot Framework possui excelentes bibliotecas internas e de terceiros que permitem iniciar e integrar rapidamente a automação nos processos de trabalho sem inventar suas próprias bicicletas - o limite de entrada muito baixo que mencionei acima.
A estrutura básica do Robot Framework é implementada usando Python e também funciona em Jython (JVM) e IronPython (.NET).
Exemplos de uso, bem como documentação completa sobre a estrutura e as bibliotecas internas, podem ser encontrados no site oficial do projeto:
http://robotframework.org/ .
Meus primeiros passos. Primeira abordagem
Pela primeira vez, me deparei com o Robot Framework um ano atrás, depois de mudar de emprego. Antes disso, eu tinha automatizado apenas em Java e C #.
Escolhendo para mim as ferramentas com as quais tenho que lidar com os testes existentes, entrevistei novos colegas sobre suas preferências. Eles não concordaram com o melhor IDE para trabalhar com o Robot Framework. Plugins para vários editores de texto e IDEs, como PyCharm, permitem principalmente trabalhar com o Robot Framework. E as recomendações que eu coletei foram divididas 50/50 entre Atom e PyCharm. Claro, existe o RIDE, mas isso não é uma panacéia. Naquela época (um ano atrás), eu não encontrei a documentação normal e, na que encontrei, não vi grandes vantagens em minha tarefa. Portanto, para iniciantes, decidi experimentar o Atom com plugins. Clonando o repositório, comecei a estudar lentamente o que estava acontecendo em nossos testes e no próprio Robot Framework.
Fui ligado ao projeto por praticamente tudo. Um monte de Jython + Robot Framework já trabalhou lá, uma enorme base de código (escrita no próprio DSL Robot Framework) foi montada a partir de mais de 1000 testes e vários milhares de linhas de código de bibliotecas auxiliares em Java.
Pelo que entendi, quando o projeto começou, ou seja, mesmo antes de eu entrar no departamento, eram principalmente os especialistas em Java que trabalhavam nele, e o produto em teste estava em Java; portanto, ao escolher uma abordagem, nos concentramos nos recursos disponíveis. Em geral, o cálculo foi algo assim: após resolver alguns problemas relacionados à integração do Robot Framework e Java (principalmente devido ao fato de Java ser uma linguagem compilada, mas o mesmo Python e testes no pacote Python + RF serem interpretados), então é fácil atrair especialistas de terceiros que conhecem apenas o DSL Robot Framework e escrever silenciosamente testes em palavras-chave. É verdade que os colegas tiveram que se esforçar bastante na criação de bibliotecas em Java; portanto, sem condições do cliente, eles não recomendariam esse caminho.
Tendo feito uma pequena refatoração, como parte da minha primeira tarefa, eu executei os testes pela primeira vez. Como o pacote Jython + RF foi usado, tudo foi coletado pelo maven e os arquivos do robô foram simplesmente copiados para o diretório de destino para execução posterior.
Os testes foram executados por scripts (arquivos .bat ou .sh) que levavam o caminho para um caso de teste separado (um arquivo .robot separado) ou para um plano de teste (um arquivo com uma lista de caminhos relativos para casos de teste).
A refatoração afetou um grande número de testes, portanto a primeira execução levou cerca de 15 minutos e, após a conclusão, é hora de examinar os relatórios fornecidos pelo Robot Framework.
O relatório padrão (na captura de tela acima) consiste nos arquivos report.html e log.html:
- o relatório contém um resumo geral da execução anterior, na qual é possível ver os resultados da superfície de todos os testes (aprovados ou reprovados);
- no arquivo de log, você pode ver informações mais detalhadas - a execução de cada teste passo a passo. Lá você pode exibir tudo o que precisa para depurar testes.
Honestamente, desde o primeiro olhar no relatório do Robot Framework, o olho começa a se mexer um pouco: uma enorme quantidade de informações é exibida e leva algum tempo para entender a estrutura de ponta a ponta dos testes e desenvolver a habilidade de ler esse log. Mas esse negócio não é tão complicado. Dentro de alguns meses, eu poderia citar The Matrix: “Seu cérebro faz a própria tradução. Eu nem vejo o código. Eu vejo uma loira, uma morena e uma ruiva. Então eu - vi todas as informações necessárias em um arquivo sem ferramentas adicionais.
A vantagem é que a saída pode ser controlada: existem diferentes níveis de registro que determinam quais informações serão exibidas e quais não. O nível pode ser ajustado mesmo para cada linha individualmente através do método da biblioteca interna. Ao mesmo tempo, saber a ordem de fazer chamadas dentro das bibliotecas auxiliares e de teste não é supérfluo - é mais fácil perceber o momento do erro.
Usando o DSL Robot Framework como nossa principal ferramenta, trabalhamos por cerca de seis meses. Durante esse período, mudei das preferências pessoais do Atom para o VSCode, mas isso não mudou a essência da abordagem.
No entanto, o projeto estava em desenvolvimento. Na iteração final, a biblioteca auxiliar para trabalhar com o banco de dados totalizou 6.700 linhas de código em um Robot Framework puro. Com essa escala da base de código, tornou-se difícil manter - refatorando os recursos necessários que não foram alocados.
A palavra final na aplicação da primeira abordagem pertencia aos negócios. O cliente do nosso projeto também trabalhou com outras equipes em tarefas relacionadas. Em uma das trilhas paralelas, ele viu, do seu ponto de vista, uma opção mais eficaz e ilustrativa para o uso do Robot Framework, que começou a ser implementado especificamente para o gerenciamento.
Segunda abordagem
A segunda abordagem foi o desenvolvimento de testes em Python em conjunto com o Robot Framework. Em vez de criar tudo na sintaxe do DSL Robot Framework, começamos a escrever bibliotecas auxiliares e outras interações de baixo nível com o produto de teste em Python. E o Robot Framework, de fato, tornou-se apenas um corredor.
Como o Python é uma linguagem pura de alto nível, não DSL, há mais opções de estruturação, é mais fácil descobrir tudo. No mínimo, você pode usar o Python IDE para ajudá-lo a encontrar os mesmos métodos (eles fazem a mesma coisa, mas são chamados de formas diferentes) ou até mesmo escrever um pedaço de código para você. Alguns dados podem ser agrupados em geradores, pendurar decoradores em funções, etc. Neste contexto, as ferramentas da primeira abordagem (pura Robot Framework) parecem bastante duras - na verdade, era o Bloco de Notas com destaque de sintaxe. Não há setters ou getters que o IntelliJ grave para você. Então, fiquei feliz em voltar para um idioma de nível superior. Trabalhar com essa abordagem é mais como um desenvolvimento normal. É verdade que há uma mosca na pomada. Sem dança adicional, é impossível entender o que ocorreu dentro do Python, chamado de RF.
Lentamente, os primeiros testes e bibliotecas auxiliares de nosso subsistema começaram a ser gravados. Durante o tempo em que pude trabalhar com uma nova abordagem, senti que, com outra ferramenta, realmente há mais oportunidades. Mas, de fato, a redação dos testes não mudou muito. Nesse projeto em particular, dentro do código Python, os métodos da biblioteca interna do Robot Framework ainda eram chamados. Isso ocorreu devido aos requisitos específicos do cliente para o desenvolvimento de testes. Simplesmente separamos a parte executável do algoritmo do caso de teste.
Qual é melhor?
Eu pessoalmente gosto da segunda abordagem. No entanto, escolhendo o caminho do seu projeto, vale a pena começar pela tarefa - quem escreve os testes e como.
Como eu disse acima, o Python (a segunda abordagem) oferece mais oportunidades, mas, neste caso, são necessárias pessoas familiarizadas com essa linguagem no projeto. O próprio Robot Framework (e a primeira abordagem) é menos exigente - você pode abordá-lo lendo a documentação oficial em sua DSL. Depois de estudar o guia do usuário, você pode criar quaisquer testes - eles ficarão bem limpos.
Como resultado, o Robot Framework e como o usamos inicialmente são mais adequados para os testadores manuais de ontem, sem nenhuma experiência explícita de programação em linguagens de alto nível. Mesmo uma pessoa que não está muito envolvida em programação pode escrever um teste, simplesmente chamando as palavras-chave necessárias.
No entanto, se você deseja manter a parte executável separada, seguindo o exemplo do nosso projeto, e ao mesmo tempo refatorar o código em IDEs amigáveis, a segunda abordagem é para você.
Autor do artigo: Dmitry Masters
PS: Publicamos nossos artigos em vários sites de Runet. Assine nossas páginas no
canal VK ,
FB ou
Telegram para descobrir todas as nossas publicações e outras notícias do Maxilect.