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 attachfrom allure_commons.types import AttachmentTypeimport allureallure.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!