Poshi — Compreendendo a estrutura e compartilhando a experiência
Poshi é uma ferramenta desenvolvida na Liferay que permite aos testadores redigir conjuntos de scripts com o objetivo de automatizar testes que simulam o comportamento de um usuário real. Este artigo vai te mostrar como funcionam as ferramentas e funcionalidades do Poshi.
Podemos começar falando sobre o porquê de automatizar testes:
“Não pense por muito tempo, faça. Mas não faça por muito tempo, pense.”
— Confúcio, filósofo chinês.
O teste automatizado é um processo no qual ferramentas de software executam testes escritos por testadores de um determinado software. Neste texto, a ferramenta é o Poshi, e o software é o portal Liferay.
Um dos maiores objetivos do teste automatizado é evitar trabalho manual em excesso, visto que o teste automatizado é adequado quando os casos de teste precisam ser executados repetidamente por um longo período de tempo. Quando um testador executa um cenário constantemente, podem ocorrer falhas ou pular algum passo importante, em suma, somos humanos e passíveis a erros.
A automatização se aplica em diversos cenários, tanto no início do desenvolvimento de um software, onde ocorrem inúmeras mudanças, quanto a softwares mais robustos e complexos, como é o caso do portal Liferay.
Devemos levar em consideração que ao automatizar testes, estamos economizando tempo e atestando mais precisamente a qualidade do software. Com a ajuda de ferramentas é possível obter métricas bem específicas, relatórios que nos permitem analisar os resultados da execução de uma suíte de teste, feedbacks mais rápido a respeito de determinados cenários, enxergar quais testes falharam ou passaram, onde e porque.
A automação é muito impactante para a produtividade e eficiência não apenas na entrega, mas também na manutenção de um software.
Leia também:
A Importância dos Testes Automatizados no Desenvolvimento de Software
Voltando ao Poshi…
Um dos produtos da Liferay é sua plataforma(Liferay DXP ou CE). Como é esperado que o usuário final use o produto principalmente por meio de sua interface de usuário(UI), testes devem ser feitos nos navegadores da web. A execução manual de testes de UI de um produto complexo como o Liferay se torna insustentável por causa dos recursos necessários para testar repetidamente uma plataforma em constante evolução. O teste automatizado torna-se o meio realista de testar continuamente o produto ao longo do tempo, identificar regressões e assim assegurar com eficiência a manutenção do produto.
Para automação de testes de UI, a Liferay optou por construir uma estrutura em cima do Selenium WebDriver. É um conjunto de ferramentas multiplataforma e de código aberto usado para automatizar testes nos navegadores web. O Selenium WebDriver fornece uma API orientada a objetos, suporta melhor as páginas dinâmicas da internet e se comunica diretamente com o Driver do navegador. Esta ferramenta é a base do Poshi.
Vale ressaltar que, qualquer máquina pessoal pode rodar o Poshi, para usar é necessário ter o repositório do liferay-portal baixado, pois o projeto da ferramenta se encontra dentro desse repositório.
O Poshi começa com a WebDriver API. Ele implementa e estende os métodos WebDriver para permitir funções ainda mais úteis que podem ir além da funcionalidade fornecida pelo Selenium. Isso concede novos métodos que permitem aos testadores da Liferay criar testes que naveguem facilmente pela UI do Liferay.
Importante frisar que todos os localizadores de objetos de página são definidos em uma única camada em Poshi. Essa camada contém uma biblioteca de centenas de localizadores de elementos de página do Liferay que podem ser usados em qualquer caso de teste.
Poshi usa uma sintaxe de script simplificada do tipo Groovy. Também foi escrito para que o testador não precise entender a camada Java para escrever novos testes, criar scripts de novos comportamentos, definir objetos de página ou criar novos métodos.
Para mim, um dos passos primordiais para me relacionar com o POSHI foi entender uma “simples” coisa:
As camadas do Poshi ajudam a manter uma lógica bem definida aos testes, a construí-los de forma mais simples, reutilzar funções e comportamentos pré-estabelecidos e também auxiliando muito na manutenção de testes antigos.
- .java — WebDriver/LiferaySelenium/WebDriverImpl
Como falamos anteriormente, a primeira e mais baixa camada Poshi é onde o WebDriver é implementado em Java. A classe base BaseWebDriverImpl implementa o WebDriver e nossa própria interface personalizada de métodos de selenium, chamada LiferaySelenium. - .function
As funções usam uma sintaxe simples para permitir que os testadores combinem os métodos básicos definidos na camada Java para criar funções reutilizáveis para casos de teste, sem necessidade de experiência em Java.
Um exemplo seria a função básica de “Click” no Poshi:
O testador chama a função de “Click” em um teste com um localizador xpath (método de pesquisa de elementos na página HTML) identificado no arquivo “path”. A função deve saber em qual elemento ou objeto da página clicar. Este localizador é passado implicitamente para a camada java como uma String.
- .path
Em vez de referenciar os localizadores em cada teste, o Poshi define os localizadores de objetos de uma determinada página em um único arquivo do Poshi, chamado de “path”. Esses localizadores são atribuídos a um nome de sua propriedade correspondente para ser usado ao chamar funções.
Os paths são referenciados nas chamadas de função no formato: PathFileName#PATH_NAME. Os nomes dos arquivos dos paths devem ser exclusivos, isso permite que ao escrever novos testes tenha acesso a qualquer path.
Os localizadores Xpath permitem encontrar elementos de forma precisa e flexível porque podem ser pesquisas HTML / XML exatas ou relativas. É importante que os paths sejam simples mas também específicos o suficiente para encontrar o objeto certo, para que não haja inconsistências nos testes e também que seja fácil de entender para os outros testadores, se tornando assim reutilizáveis em todo o projeto.
Para entender um pouco mais:
- .macro
Já discutimos um pouco sobre as camadas mais internas do Poshi, nessa camada podemos dizer que é onde começamos a juntar as peças, as .function e .path que conversamos anteriormente são então chamadas e aqui definimos as interações dos usuários.
Os arquivos de macros geralmente são nomeados com base nos componentes que estamos executando ou referente às rotinas que estamos definindo.
Na minha cabeça, começamos a orquestrar uma macro sempre que identificarmos um comportamento, desde clicar em um botão, realizar navegações, ler informações, garantir que determinados elementos estão presentes, fazer login, adicionar um Blog, analisar métricas, criar rotinas, checar as funcionalidades do produto, entre outros. Podemos também fazer coisas mais avançadas como enviar chamadas de API para melhorar a velocidade de configuração do teste.
O Liferay Portal tem um recurso de publicação de blogs. Parte desse recurso é a entrada individual do blog. Então foi criado o arquivo BlogsEntry.macro, onde são definidas todas as interações do usuário com esse recurso.
Aqui podemos identificar o arquivo BlogsEntry.macro e também duas macros presentes nesse arquivo, uma para adicionar o título e outra para adicionar o subtítulo de um blog, conseguimos identificar o uso da função “Type”, e a presença dos respectivos localizadores, para podermos constatar precisamente os elementos que estamos querendo encaixar nessa “rotina”.
- .testcase
Até aqui temos quase tudo definido, conversamos sobre as camadas que considero nossas ferramentas e materiais para obra, podemos então de fato levantar a parede ⚒👷♂️🧱. Agora o testador pode escrever um caso de teste combinando as rotinas (macros), passando os parâmetros esperados e variáveis necessárias para certificar de que o Portal está se comportando conforme o esperado.
Para deixar um pouco mais claro, vamos falar um pouco mais sobre um dos projetos da Liferay, o Workflow.
Nesse projeto nós criamos literalmente Workflows, fluxos de trabalho simples a complexos, podemos implantá-los em algum asset do portal e gerenciá-los por meio de uma interface do portal. Na imagem acima, podemos ver Workflows criados, e, se olharmos atentamente, veremos que temos alguns publicados e outros não publicados. Abaixo veremos um caso de teste onde o objetivo é garantir que o usuário pode duplicar um Workflow que esteja com o status “Not Published”.
Podemos ver que há uma estrutura no teste, temos uma description que fornece como uma sinopse do teste, algumas propriedades necessárias para ambientar o teste, o nome e em seguida, o passo a passo, as rotinas. Nesse teste foram utilizadas 5 macros, ordenadas de acordo com o que queremos reproduzir.
— ApplicationsMenu.gotoPortlet ~ (Ir até a area do Process Builder)
— Workflow.unpublishWorkflowDefinition ~ (Tornar o Workflow Unpublished)
— ApplicationsMenu.gotoPortlet ~ (Voltar até a área do Process Builder)
— Workflow.viewDefinitionUnpublished ~ (Garantir que o Workflow
referenciado está de fato Unpublished)
— Workflow.duplicateNotPublishedWorkflow ~ (Duplicar o Workflow que não está publicado)
— Navigator.gotoBack ~ (Clicar no botão de “back” para retornar a página anterior)
— Workflow.viewDefinitionUnpublished ~ (Garantir que o Workflow referenciado segue Unpublished)
— Workflow.viewDefinitionUnpublished ~ (Garantir que o Workflow referenciado está de fato Unpublished)
Se a gente parar para olhar um pouco mais devagar, o primeiro passo desse teste seria ir para o Workflow, mas assim, quando o teste começar a rodar, executar direto esse passo é o correto a ser feito? Não há nada que precise ser feito antes?
Nesse caso, o teste está em um arquivo .testcase chamado “ProcessBuilderListView”, dentro desse arquivo tem os mais diversos testes respectivos daquela área do portal, mas para iniciá-los é necessário um “setUp”, que vai rodar toda vez que um teste iniciar. No caso desse arquivo especificamente, foi programado um setup curto, apenas o login, mas isso vai variar de acordo com a necessidade de cada cenário.
Além do setup para iniciar, precisamos também de algo para finalizar, o “tearDown”, que vai executar sempre que o teste que for escrito acabar de rodar, também podendo variar de acordo com a necessidade de arquivo para arquivo.
Por fim, com calma e organização, entendendo bem o fluxo e as camadas do poshi, qualquer um é capaz de desenvolver testes com facilidade e diversão, um passo de cada vez e bastante café, que depois disso tudo ainda roda na CI, mas ai eu deixo para vocês descobrirem! 👀😆
A seguir vocês podem conferir um vídeo com o processo de um teste, reproduzindo manualmente e mostrando a vocês a composição do código antes de botar para rodar.
Viram que não tem mistério né? Apesar de estar falando de testes “automáticos”, a melhor forma de aprender cada vez mais é com a mão na massa, com calma, tijolinho por tijolinho, que a gente constrói nosso conhecimento e faz acontecer!
Para mais informações:
https://qa-compendium.readthedocs.io/en/latest/poshi/index-poshi.html
