Behave-allure integration (Português)

Observação: este texto ainda está sendo feito a medida que o desenvolvimento e a configuração do allure que eu estou fazendo estiver em estudo, cada nova descoberta será colocada no texto

Report:

O report do allure mostra os dados de acordo com a execução, ou seja se alguma feature tiver um esquema de cenário, cada execução será uma Suíte mostrada no allure, e também cada linha do esquema de cenário da feature gera um arquivo json de report.

Categorias:

As categorias são divididas em outro arquivo json chamado “categories.json” na pasta de report junto com os jsons de report gerados pelo allure, que faz um chain/match com a informação que foi gerada pelo behave, ele pode realizar filtros de informação e separá-los em categoria(sugestão: crie um arquivo com todas as categorias possíveis e use o mesmo como padrão, pois todas as possibilidades que podem dar nos testes serão catalogadas e mostradas no report final sem que seja preciso alterá-las)

[
{
"name": "Testes ignorados",
"matchedStatuses": ["skipped"]
},
{
"name": "Defeito no teste",
"matchedStatuses": ["broken"]
},
{
"name": "Defeito no produto",
"matchedStatuses": ["failed"]
},
{
"name": "Testes que passaram",
"matchedStatuses": ["passed"]
}
]

Também é possível definir exceções para as categorias, como por exemplo esta parte do json que pode ser adicionado, que se houver a exceção de elemento não encontrado, ele separa em uma categoria:

{
"name": "Elemento não encontrado",
"traceRegex": ".*NoSuchElementError.*",
"matchedStatuses": [ "failed" ]
}

Ambiente:

Existem duas formas de mostrar o ambiente que foi executado os testes no allure report, ambas são fáceis de se configurar, a primeira forma, mais fácil, é um arquivo “environment.properties” no qual você pode colocar o ambiente como bem desejar, exemplo:

Navegador=Google chrome

Chrome_version=78.0.3904.87 64 bits

Ambiente=Feature

Link_ambiente=http://feature.com/#/login

a segunda forma seria criar um arquivo “environment.xml”, esse sendo necessário realizar as configurações acima usando um xml, que funcionará da mesma forma, exemplo:

<?xml version=”1.0" encoding=”UTF-8"?>
<environment>
<parameter>
<key>Navegador</key>
<value>Google Chrome</value>
</parameter>
<parameter>
<key>Versão do Chrome</key>
<value>78.0.3904.87 64 bits</value>
</parameter>
<parameter>
<key>Ambiente</key>
<value>Feature</value>
</parameter>
<parameter>
<key>Link do ambiente</key>
<value>http://feature.com/#/login</value>
</parameter>
</environment>

ambos arquivos ficam localizados na pasta de reports do allure (necessário apenas um para que funcione)

Screenshots:

É possível também adicionar Screenshots aos steps com o seguinte código:

from allure_commons._allure import attach
from allure_commons.types import AttachmentType
import allure
allure.attach(context.browser.get_screenshot_as_png(), name='Screenshot', attachment_type=AttachmentType.PNG)

A definição de em que momento usar screenshots para melhorar o report de testes vai de quem usa, se quer que seja após cada step, adicione uma função “after_step” ao environment.py para que seja tirada a screenshot a cada step, se quiser que seja apenas quando houver um erro no step basta colocar um “if” como no seguinte exemplo:

def after_step(context, step):
    if step.status == "failed":      
        allure.attach(context.browser.get_screenshot_as_png(), name='Screenshot', attachment_type=AttachmentType.PNG)

E por fim, se quiser por em algum step específico, basta colocar o código no seu step, sem esquecer dos imports.

Trending/Histórico de execuções:

O histórico de tendências serve principalmente para exibir em gráficos as features que foram executadas naquele instante, tão como se é uma feature nova ou uma nova execução de uma antiga, o tempo que elas tomaram para ser executadas e suas categorias.

O histórico de execução, apesar de guardar todos os arquivos jsons na pasta definida, exibirá apenas as ultimas 20 execuções em seu gráfico.

Eu dividi os comandos para a execução do histórico em três partes, primeira, segunda e terceira execução, mesmo a segunda e a terceira execução tendo pouca diferença tem um passo importante que deve ser considerado. Também vale ressaltar que a terceira execução pode ser replicada para todas as futuras execuções que podem ser feitas.

• Primeira execução:

behave -f allure_behave.formatter:AllureFormatter -o allure/results ./features

Nesse primeiro comando é definido o formatador e a pasta de saida dos json de report, Se no seu “behave.ini” estiver definido o formatador e o caminho apenas execute o comando “behave ./features”. É mais interessante que seja retirado do “behave.ini” para que o report possa ser executado em qualquer máquina, até as que não estão com o arquivo.

allure generate allure/results/ -o allure/reports

Esse segundo comando gera a pasta do allure report e joga essa primeira execução nos arquivos da pasta “history” dentro dessa mesma que foi gerada.

Então basta abrir o allure report com o seguinte comando:

allure open allure/reports

Observação: é Sempre é bom definir os arquivos das categorias e do ambiente desde o inicio, já que esses arquivos normalmente não são alterados de forma rotineira e servem de fonte de informações importantes e de padronização de report.

• Segunda execução:

Repetimos o comando de execução:

behave -f allure_behave.formatter:AllureFormatter -o allure/results ./features

E então devemos copiar a pasta de histórico gerado para a pasta de results para gerar um novo report com o seguinte comando:

cp -R allure/reports/history allure/results/history

Mas por que é importante que essa pasta seja copiada?
Quando foi gerado o primeiro report da primeira execução ele pegou o report e gerou na pasta do allure, agora temos novos reports, ou seja, com essa cópia nós estamos adicionando o histórico da execução antiga a execução nova, criando assim o próprio histórico de execuções, sem esse comando ele enxergará essa nova execução como a primeira, o que não é desejado.

Então vamos gerar o report dessa nova execução:

allure generate allure/results/ -o allure/reports --clean

E abrir o report:

allure open allure/reports

É possível notar a diferença, tanto na parte inicial quanto na parte de gráficos.

• Terceira execução:

Executamos o behave:

behave -f allure_behave.formatter:AllureFormatter -o allure/results ./features

E aqui está a diferença da segunda execução, antes de copiar a pasta de histórico de report para results, devemos apagar a pasta antiga. A pasta pode ser deletada manualmente sem problemas mas como estou executando os comandos em powershell com VSCode apenas executei o comando:

Remove-Item .\allure\results\history\ -Recurse

Só então podemos copiar a pasta de histórico:

cp -R allure/reports/history allure/results/history

Gerar o report da terceira execução:

allure generate allure/results/ -o allure/reports --clean

E abrir o report:

allure open allure/reports

A partir daqui é só repetir os passos da terceira execução que o histórico do allure funcionará perfeitamente.

Também é importante citar o Allure reports portal, em que podem ser adicionados os reports de várias execuções, mas não irei entrar em muitos detalhes no momento.

Organização de pasta exemplo após a terceira execução:

C:.
├───.vscode
├───allure
│   ├───reports
│   │   ├───data
│   │   ├───export
│   │   ├───history
│   │   ├───plugins
│   │   └───widgets
│   └───results
│       └───history
├───features
│   ├───profiles
│   ├───steps
│   └───TC
└───tools

Agradecimentos:

Esse texto só foi possível graças a equipe em que faço parte, Rebecca como minha lider me apresentou ao mundo de QA e me encorajou a escrever esse texto, jeckson me ajudou na definição de como funcionava o allure e nas pesquisas incessantes na internet sobre seu funcionamento tão como ajudou no incentivo para que isso fosse escrito, karol foi a descobridora de como a automação do próprio allure, e gabriel com apoio e explicações. Sem essa equipe esse texto não existiria nem eu saberia nada sobre esse assunto, obrigado!