Desenvolvimento Guiado por Comportamento (Behavior Driven Development - BDD)

Vanilton Pinheiro

https://vanilton.net

Quem sou eu?

Vanilton Pinheiro

Analista de Sistemas

Aquecendo os motores

Nossas ferramentas

IDE PyCharm Community ou Professional
Linguagem Python 3.7+
Provisionar Ambiente Docker
Sistema Operacional Windows
Linux
macOS

Introdução ao Behavior Driven Development

  • O que é BDD e por que é importante?

  • Comparação entre BDD, TDD (Test Driven Development) e DDD (Domain Driven Development).

  • Benefícios do BDD no desenvolvimento de software.

  • Quando e onde aplicá-lo.

1

O que vocês já ouviram falar de BDD?

O BDD é uma metodologia ágil de desenvolvimento que enfatiza a colaboração entre desenvolvedores, testadores e partes interessadas para criar software que realmente atenda às necessidades do cliente e com alta capacidade de automação.

O que é BDD?

1. Introdução ao Behavior Driven Development

Ferramenta de teste

Lento

Exigente por Automação

Limitado a um nível de teste 

O que BDD não é?

1. Introdução ao Behavior Driven Development

O BDD foi desenvolvido em 2003 por Dan North (jovem ao lado). Na época, ele percebeu a dificuldade de muitas equipes ao adotar o Test Driven Development (TDD) ou, em português, Desenvolvimento Orientado por Testes, criado por Kent Beck, pelo fato de os testes serem criados antes do código.

Como surgiu?

1. Introdução ao Behavior Driven Development

Dan North reescreveu o framework em Ruby - RBehave

2003 - Dan North criou um framework BDD - JBehave

2005 - Integração do RBehave ao projeto RSpec

Dan trabalhou com David Chelimsky, Aslak Hellesøy e outros para desenvolver RSpec e escrever o livro RSpec Book

2008 - RSpec foi depois substituido por Cucumber desenvolvido príncipalmente por Aslak Hellesøy.

1. Introdução ao Behavior Driven Development

Alguns marcos importantes

  • Quantos profissionais em diferentes papéis você interage durante o desenvolvimento?
  • Qual a maior dificuldade para se desenvolver o produto certo?

Por quê BDD?

1. Introdução ao Behavior Driven Development

  • Foco na compreensão do comportamento do software a partir da perspectiva do usuário.
  • Uso de linguagem natural para definir requisitos e especificações.
  • Integração estreita entre desenvolvimento, testes e análise de negócios.

Características do BDD

1. Introdução ao Behavior Driven Development

1. Compreensão Compartilhada:

  • Permite que todas as partes interessadas tenham uma visão clara das funcionalidades.

Benefícios em adotar BDD

1. Introdução ao Behavior Driven Development

2. Colaboração Melhorada:

  • Promove a comunicação e colaboração entre desenvolvedores, testadores e partes interessadas.​​​​​​​

Benefícios em adotar BDD

1. Introdução ao Behavior Driven Development

3. Testes Automatizados Significativos:

  • Testes automatizados baseados em comportamento, fornecendo feedback rápido e relevante.

Benefícios em adotar BDD

1. Introdução ao Behavior Driven Development

4. Foco no Valor:

  • Ajuda a construir exatamente o que é necessário para atender às necessidades do cliente.

Benefícios em adotar BDD

1. Introdução ao Behavior Driven Development

Trazendo a luz para a sopa de letrinhas *DD

1. Introdução ao Behavior Driven Development

2. Modelar as Entidades

  • Atributos
  • Comportamentos

1. Identificar os principais conceitos do domínio

3. Definir os agregados

  • Entidades relacionadas

4. Fábrica de instâncias

  • Criar instâncias das entidades de forma consistente

5. Desenhar os Repositórios

  • Recuperar e armazenar as entidades no banco de dados

Contexto

Considere que estamos desenvolvendo um sistema de e-commerce. O domínio principal é o gerenciamento de produtos, pedidos e clientes.

1. Introdução ao Behavior Driven Development

1.1 DDD - Case

6. Política de negócio

  • Regra de negócio para as entidades

Linguagem Ubiqua

Iterar e Refinar

1. Introdução ao Behavior Driven Development

1.1 DDD - Benefícios

Prática

Crie o projeto Python para iniciar os testes utilizando TDD

1. Introdução ao Behavior Driven Development

1.1 TDD - Case - Criando o projeto Python no PyCharm

2. Executar o Teste

  • Esperar a falha

1. Escrever um Teste para uma entidade

3. Implementar o código fonte

  • Mínimo Necessário

4. Rodar o Teste Novamente

  • Esperar o teste passar

Contexto

Considere que estamos desenvolvendo um sistema de e-commerce. O domínio principal é o gerenciamento de produtos, pedidos e clientes.

1. Introdução ao Behavior Driven Development

1.1 TDD - Case

Iterar e Refinar

1. Introdução ao Behavior Driven Development

1.1 TDD - Benefícios

TDD x BDD

1. Introdução ao Behavior Driven Development

Quando usar BDD?

1. Introdução ao Behavior Driven Development

PO

Cliente

Designer

Você

Cenários e Especificações

  • Compreensão dos cenários de comportamento.

  • Escrevendo especificações claras e concisas.

  • Definindo a diferença entre cenários positivos e negativos.

  • Estrutura de um cenário: Given-When-Then.

2

Valor entregue

o que será feito?

1.

Jornada

Como será feito?

Exemplos

2.

Identificação do Valor

Por quê será feito?

3.

Área de Negócio

Utilizam terminologias de sua área

  • Campo pra selecionar

Computador

Utiliza linguagem de programação para computar e traduzir tudo em binário

Desenvolvedor

Utilizam termos advindos da tecnologia

  • Combobox

2. Cenários e Especificações

Amazon.com.br é um(a)...?

2. Cenários e Especificações

Linguagem Ubíqua

Uso de linguagem comum e compartilhada por todas as partes interessadas em um projeto de software, incluindo desenvolvedores, testadores, especialistas de domínio e clientes.

2. Cenários e Especificações

  1. Requisitos (User Stories)
  2. Documentos
  3. E-mails
  4. Reuniões

Linguagem Ubíqua pode ser utilizada:

2. Cenários e Especificações

  1. Menos risco de falta de entendimento

  2. Comunicação mais rápida e direta

  3. Conhecimento do domínio por todos

  4. Entendimento/clarificação de código

     

     

     

Linguagem Ubíqua algumas vantagens:

2. Cenários e Especificações

De forma muito resumida, linguagem ubíqua é: Todos falando a mesma língua e usando as mesmas palavras para definir as mesmas coisas.

2. Cenários e Especificações

User Story

2. Cenários e Especificações

User Story

2. Cenários e Especificações

INDEPENDENTE

NEGOCIÁVEL 

VALIOSA

ESTIMÁVEL 

SOB MEDIDA

TESTÁVEL

2. Cenários e Especificações

O usuário efetua o login com usuário e senha válido e visualiza a tela com diversos campos

O estudante efetua o login com usuário e senha válido e visualiza a lista de provas marcadas para o dia

O usuário efetua o login com usuário e senha válido e visualiza a tela com diversos campos

2. Cenários e Especificações

class Tela:
    def exibir(self):
        print("Bem-vindo à Tela Principal!")
        print("Aqui estão os diversos campos:")
        print("Campo 1: [       ]")
        print("Campo 2: [       ]")
        print("Campo 3: [       ]")

        
class Sistema:
    def __init__(self):
        self.usuarios = [
            Usuario(nome_usuario="usuario123", senha="senha123")]

    def login(self, nome_usuario, senha):
        for usuario in self.usuarios:
            if usuario.nome_usuario == nome_usuario and usuario.senha == senha:
                tela = Tela()
                tela.exibir()
                return True
        return False

O usuário efetua o login com usuário e senha válido e visualiza a tela com diversos campos

2. Cenários e Especificações

class Estudante:
    def __init__(self, nome_usuario, senha):
        self.nome_usuario = nome_usuario
        self.senha = senha

class Prova:
    def __init__(self, disciplina, data, horario):
        self.disciplina = disciplina
        self.data = data
        self.horario = horario


class Sistema:
    def __init__(self):
        self.estudantes = [
            Estudante(nome_usuario="estudante123", senha="senha123")]
        
        self.provas = [
            Prova(disciplina="Matemática", data="2023-09-15", horario="09:00"),
            Prova(disciplina="História", data="2023-09-15", horario="14:00"),
        ]

     def listar_provas_do_dia(self):
      ....

O estudante efetua o login com usuário e senha válido e visualiza a lista de provas marcadas para o dia

2. Cenários e Especificações

O estudante efetua o login com usuário e senha válido e visualiza a lista de provas marcadas para o dia

Cenário

  • Descrevem como o sistema deveria funcionar em situações ideais, onde todas as entradas são válidas e as condições estão alinhadas para o sucesso da operação.

Cenário

  • Exploram como o sistema se comporta em situações não ideais, onde as entradas podem ser inválidas, incompletas ou em conflito com as regras de negócio.

2. Cenários e Especificações

  • Um Critério de Aceitação também chamados de ACs (do inglês, acceptance criteria) é onde expressamos como iremos garantir que um requisito (user story) será, além de testável, validado e entendido pelo cliente e qualquer pessoa do time. Além do mais fornecem uma lista de verificação que determina quando uma história de usuário está concluída, completa e funcionando.
  • Para descrever o ACs ou critérios de aceite pode-se utilizar a notação Gerkin Given–When–Then que conheceremos logo mais.

Critério de Aceitação

Linguagem Gherkin

  • Introdução à linguagem Gherkin.

  • Sintaxe básica do Gherkin para escrever cenários.

  • Uso de palavras-chave: Given, When, Then, And, But.

  • Dicas para escrever especificações legíveis.

3

Gherkin é uma linguagem que foi criada especialmente para descrições de comportamento, ela tem a capacidade de remover detalhes da lógica de programação e focar no comportamento que uma funcionalidade deve ter.

O que é Gherkin?

3. Linguagem Gherkin

3. Linguagem Gherkin

Onde estamos usando Gherkin?

Given (Dado)

  • Descrição das condições do cenário

1.

Given (Dado)

  • Descrição das condições do cenário

1.

When

  • Descrição da ação do cenário quando for executado

2.

Then (Então)

  • Descrição do resultado esperado após execução do cenário.

3.

And, But (E, Mas)

  • Como usá-las para tornar os cenários mais expressivos ou sucessivos Given, When, Then.

4.

Funcionalidade (Feature): Função a ser realizada

Cenário (Scenario): Exemplo a ser verificado

3. Linguagem Gherkin

Exemplos

3. Linguagem Gherkin

Given o usuário está logado
And o saldo da conta é $1000
When o usuário tenta sacar $1200
Then o sistema deve exibir uma mensagem de erro
But o saldo da conta ainda deve ser $1000
Given o usuário está logado
And a página principal é carregada
When o usuário clica no botão "Adicionar Item"
And preenche o formulário com os seguintes detalhes:
| Campo      | Valor        | Quantidade |
| Nome       | Novo Item    | 5          |
Then o novo item deve ser exibido na lista de itens

Engenharia reversa

  • Vamos exercitar o entendimento de leitura de estória.

3. Linguagem Gherkin

  • Priorize o que é de suma importância

  • Separe texto de código

  • Descreva cenários em terceira pessoa

  • Utilize tabelas para exemplos e facilitar o entendimento

  • Exponha o "o quê" mais que "o como"

Dicas

3. Linguagem Gherkin

Procure os erros conforme as Dicas

3. Linguagem Gherkin

Reescrevendo cenário

3. Linguagem Gherkin

Integração de BDD no Ciclo de Desenvolvimento Ágil

  • Colaboração entre desenvolvedores, testadores e partes interessadas.

  • Identificação e envolvimento das partes interessadas.

  • Incorporando práticas de BDD no planejamento e estimativas ágeis.

  • Como BDD afeta o desenvolvimento iterativo e incremental.

4

Um dos benefícios das estórias de usuários é que elas capturam uma necessidade em uma única frase. Então você sabe que a estória do usuário requer mais informações e que você precisa conversar  no  momento apropriado com sua equipe

Organizar um workshop de requisitos ou uma sessão de planejamento é uma ótima maneira de fazer com que toda a equipe tenha essas conversas.

Por onde começar?

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

Desenvolvimento de fora para dentro

Especificação por Exemplo

Como fazer?

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

  • Diretores: As pessoas que compram seu software – as partes interessadas mais importantes a serem apaziguadas.
  • Usuários finais: as pessoas que interagem com seu produto. Eles experimentam como seu software funciona no mundo real.
  • Parceiros: As pessoas que fazem seu produto funcionar na vida real, como equipes de operações e também parceiros de negócios e integradores de sistemas.
  • Insiders: as pessoas da sua empresa que têm algum impacto na forma como sua equipe desenvolve software.

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

4.1 Outside-In Development

As partes interessadas

2. Levantar e implementar demandas que impacte as partes interessadas

1. Antes de desenvolver é crucial falar com todas as partes interessadas, mesmo que elas não sejam o público principal do seu software.

3. Programar apenas o mínimo necessário (MVP)

4. Solicitar feedback útil

Contexto

Desenvolvimento de fora para dentro tem como foco atender as partes interessadas sendo uma abordagem que pode ser aplicada em times lean/ágeis.

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

4.1 Outside-In Development

Partes interessadas

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

2. Realize um workshop de requisitos com toda a equipe (quadro branco obrigatório!) para discutir as estórias de usuários escolhidas.

1. Escrever estórias com antecedência

3. Faça um brainstorming de uma lista de exemplos para cada estória de usuário.

4. Escolha um conjunto representativo de exemplos.

5. Traduza cada exemplo em um teste de aceitação (no formato Gherkin).

6. Guarde toda essa documentação em um local de fácil acesso.  

4.2 Specification Workshops (Three Amigos)

Melhor qualidade dos requisitos

- Compartilhamento do risco

1.

Perspectivas mais variadas

- Diferentes perfis e experiências

2.

Níveis mais elevados de consenso

3.

O que ganhamos com Workshops?

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

Maior adesão 

- Senso de pertencimento

4.

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

Dinâmica

4. Integração de BDD no Ciclo de Desenvolvimento Ágil

Automação de Testes com BDD

  • Visão geral da automação de testes em BDD.

  • Introdução às ferramentas populares de BDD (Cucumber, SpecFlow, Behave, Pytest-BDD etc.).

  • Configuração de cenários de teste automatizados.

  • Execução e interpretação dos resultados dos testes automatizados.

5

5. Automação de Testes com BDD

Lento

Rápido

$$$

$

# de testes

  • Automação de API
  • Contrato ou Mock
  • Unitário
  • Automação Funcional

Onde está o valor para as partes interessadas?

Ferramentas

5. Automação de Testes com BDD

Ferramentas

5. Automação de Testes com BDD

Ferramentas

5. Automação de Testes com BDD

Ferramentas

5. Automação de Testes com BDD

 BDD

  • pytest-bdd implementa um subconjunto da linguagem Gherkin
  • Não requer um executor separado
  • Se beneficia do poder e da flexibilidade do pytest

Instalando Biblioteca

5. Automação de Testes com BDD

# Biblioteca BDD
pip install pytest-bdd 

# Biblioteca para manipular páginas web
pip install pytest-playwright 

Vamos instalar as dependências:

Instalando Plugins

5. Automação de Testes com BDD

1. No PyCharm procurar/instalar os seguintes plugins abaixo:

2. Reinicie sua IDE

Estruturando o projeto

5. Automação de Testes com BDD

Configure uma das seguinte estruturas de pastas:

features
│
├──frontend
│  │
│  └──auth
│     │
│     └──login.feature
└──backend
   │
   └──auth
      │
      └──login.feature

Organize seus arquivos de recursos nas pastas por grupos semânticos:

Estruturando o projeto

5. Automação de Testes com BDD

feature:

Neste pasta será incluído os arquivos *.feature utilizandos pela ferramenta para identificar as escritas de comportamento no formato Gherkin.

Por padrão, pytest-bdd usará o caminho do módulo atual como caminho base para localizar arquivos de recursos, mas esse comportamento pode ser alterado no arquivo de configuração pytest (ou seja, pytest.ini, tox.ini ou setup.cfg) declarando o novo caminho base na chave bdd_features_base_dir. O caminho é interpretado como relativo ao diretório raiz do pytest. Você também pode substituir o caminho base dos recursos por cenário, para substituir o caminho para testes específicos.

Estruturando o projeto

5. Automação de Testes com BDD

steps:

Neste pasta será incluído as implementações referentes aos arquivos .feature

tests
│
└──functional
   │
   └──test_auth.py
      │
      └ """Authentication tests."""
        from pytest_bdd import scenario

        @scenario('frontend/auth/login.feature')
        def test_logging_in_frontend():
            pass

        @scenario('backend/auth/login.feature')
        def test_logging_in_backend():
            pass

Prática

5. Automação de Testes com BDD

  1. Crie o arquivo de feature cliente.
  2. Vamos gerar os steps
  3. Implementar os steps
Feature: Cliente se identificar no ecommerce
  Como cliente de loja
  gostaria de me autenticar
  para realizar compras.

  Scenario: Cliente autenticando na loja
    Given o cliente possui registro na loja
    Then o sistema confirma a autenticidade do cliente

Prática

5. Automação de Testes com BDD

  1. Crie o arquivo de feature cliente
  2. Gere os steps
  3. Implemente os steps
  4. Execute o cenário
Feature: Cliente se identificar no ecommerce
  Como cliente de loja
  gostaria de me autenticar
  para realizar compras.

  Scenario: Cliente autenticando na loja
    Given o cliente possui registro na loja
    Then o sistema confirma a autenticidade do cliente

Gerando Steps

5. Automação de Testes com BDD

A medida que escrevemos nossos arquivos .feature, precisamos gerar sua implementação incluída posteriormente nos steps

# Gerando todos steps
pytest-bdd generate tests/bdd

# Gerando steps e criando arquivo de steps
pytest-bdd generate features/some.feature > tests/functional/test_some.py

# Gerando apenas steps pendentes
pytest --generate-missing --feature tests/bdd/features

Executando

5. Automação de Testes com BDD

  1. No terminal faça os comandos abaixo:
# Execução simples
pytest

# Executando e visualizando resultados no terminal
pytest --gherkin-terminal-reporter -v

Executando

5. Automação de Testes com BDD

  1. Na IDE inclua uma Configuração de Run/Debug para o pytest:

Decorators

5. Automação de Testes com BDD

from pytest_bdd import (
    given,
    when,
    then,
    scenario
)

@scenario('minha.feature', 'Minha Feature')
def test_minha_feature(foo):
    assert foo2.title in foo.value
  1. Todo cenário terá uma função de teste que será chamada ao seu final.
  2. Experimente tirar o prefixo test da função e executar o teste.

Nomeando passos

5. Automação de Testes com BDD

  1. Em alguns momentos para melhorar a leitura nomeamos passos ou fixtures iguais com sintaxes diferente, para isso:

Injeção (Fixtures)

5. Automação de Testes com BDD

Sobrescrita de Fixtures

5. Automação de Testes com BDD

@pytest.fixture
def cliente():
    cliente = Cliente(nome="Jão", email="jao@gmail.com")
    return cliente


@given('o cliente possui registro na loja', target_fixture="cliente")
def verificar_cliente_registro_loja():
    """o cliente possui registro na loja."""
    cliente = Cliente(nome="vava", email="jao@gmail.com")
    return cliente


@then('o sistema confirma a autenticidade do cliente')
def verificar_cliente_criado(cliente):
    assert cliente.nome is "Jão"

A beleza do link

5. Automação de Testes com BDD

Preparando nosso ambiente

5. Automação de Testes com BDD

  1. Garanta que esteja com o Docker em execução na sua máquina
  2. Clone o projeto: https://github.com/smokysk/shop-django-rest-framework/tree/develop
  3. Acesse a pasta do projeto
  4. Execute os comandos abaixo:
# Criar a rede para os serviços
docker network create backend

# Subir os serviços
docker compose up -d

# Criar o usuário adminstrador
docker compose run --rm shop-bdd python manage.py createsuperuser

Nossa aplicação

5. Automação de Testes com BDD

api/v1/

api/v1/product/
api/v1/product/?search={query}
api/v1/category/
api/v1/category/?search={query}
api/v1/user/
api/v1/cart/
api/v1/cart/?search={query}
api/v1/cart/add/
api/v1/cart/delete/{pk}/
api/v1/cart/add_one/{pk}/
api/v1/cart/reduce_one/{pk}/

auth/

auth/login/
auth/login/refresh/
auth/register/
auth/change_password/{pk}/
auth/update_profile/{pk}/
auth/logout/
auth/change_image/
auth/delete_profile/{pk}/

Prática

5. Automação de Testes com BDD

1. Considere a seguinte feature da API Shop:

Autenticação, elabore um cenário .feature que realize o login no sistema

2. Utilizando Playwright API Testing vamos implementar o stes

Prática

5. Automação de Testes com BDD

1. Considere a seguinte feature da API Shop:

Cadastrar categoria, elabore um cenário que realize esse comportamento

2. Implemente o feature utilizando Playwright API Testing

Documentação da API: http://127.0.0.1:8000/doc/#operation/api_category_create

 

Endpoint para criação da categoria

http://127.0.0.1:8000/v1/api/category/

Organizando Cenários

5. Automação de Testes com BDD

Organizando por pastas não conseguimos distinguir os cenários contidos nas features, e sim apenas executá-la por completo. Logo para realizar essa distinção utilizamos Tags

pytest -m "integration" --gherkin-terminal-reporter -v

pytest -m 'integration or successful' --gherkin-terminal-reporter -v

pytest -m 'not integration'

Estruturando o projeto

5. Automação de Testes com BDD

Realizando configurações para execução:

[pytest]
bdd_features_base_dir = tests/bdd/features/
pythonpath = .

Feature

5. Automação de Testes com BDD

Argumentos

 

  1. string
  2. parse

Parsers

5. Automação de Testes com BDD

@given(parsers.parse('o cliente "{nome:w}" possui registro na loja'))
def verificar_cliente_na_loja_por_nome(nome):
    print(nome)

    
@given(parsers.parse("há {total:d} laranjas"), target_fixture="laranjas")
def ha_laranjas(total):
    return {"total": total, "comida": 0}
    Scenario: Argumento para os passos given, when, then
        Given há 5 laranjas
        When como 2 laranjas
        And como 2 laranjas
        Then deve haver 1 laranja

Parsers - Tabular

5. Automação de Testes com BDD

@given(parsers.parse('o cliente "{nome:w}" possui registro na loja'))
def verificar_cliente_na_loja_por_nome(nome):
    print(nome)

    
@given(parsers.parse("há {total:d} laranjas"), target_fixture="laranjas")
def ha_laranjas(total):
    return {"total": total, "comida": 0}
Feature: Exemplo com tabela

    Scenario Outline: Comer laranjas com argumento tabulados
        Given há <total> laranjas
        When como <comer> laranjas
        Then deve haver <restante> laranja

        Examples:
        | total | comer | restante |
        |  12   |  5    |  7       |
        |  50   |  10    |  40       |

Cenário outline deve estar em um feature separado de cenário isolado.

Parsers - Dicionário

5. Automação de Testes com BDD

Feature: pokédex search
  As a Pokemon trainer,
  I want to search for pokemons in my pokédex,
  So I can learn more about them.

  Background:
    Given the pokédex page

  Scenario Outline: Name pokédex search
    When the user searches for "<text>"
    Then the "<pokemon>" information is shown

    Examples: Pokemons
      | text       | pokemon    |
      | Pikachu    | Pikachu    |
      | Charmander | Charmander |
@then(parse('the "{pokemon}" information is shown'), converters=dict(pokemon=str))
def the_pokemon_information_is_shown(pokemon_located, pokemon):

    assert pokemon_located.__len__() > 0
    assert pokemon in pokemon_located["nome"]

Scenario outline

5. Automação de Testes com BDD

Gerando report Cucumber

5. Automação de Testes com BDD

Execute pytest passando a opção abaixo:

pytest --cucumberjson=report.json

5. Automação de Testes com BDD

Relatório com Allure Report

Allure é uma ferramenta de relatório de teste leve e flexível em vários idiomas projetada para criar relatórios de teste sofisticados e claros.

 

5. Automação de Testes com BDD

Relatório com Allure Report

O Allure funciona conforme imagem abaixo:

 

5. Automação de Testes com BDD

Relatório com Allure Report

Para utilizá-lo vamos seguir os seguintes passos:

  1. Subir o Server e UI do Allure
  2. Instalar biblioteca para gerar o resultado allure
  3. Gerar o report de teste e postar no server Allure

5. Automação de Testes com BDD

Relatório com Allure Report

Server e UI Allure

# docker-compose.yml
version: '3'

services:
  allure:
    image: "frankescobar/allure-docker-service"
    environment:
      CHECK_RESULTS_EVERY_SECONDS: 1
      KEEP_HISTORY: 1
    ports:
      - "5050:5050"
    volumes:
      - ${PWD}/allure-results:/app/allure-results
      - ${PWD}/allure-reports:/app/default-reports

  allure-ui:
    image: "frankescobar/allure-docker-service-ui"
    environment:
      ALLURE_DOCKER_PUBLIC_API_URL: "http://localhost:5050"
      ALLURE_DOCKER_PUBLIC_API_URL_PREFIX: ""
    ports:
      - "5252:5252"

5. Automação de Testes com BDD

Relatório com Allure Report

Instalar e Publicar resultado de teste com Allure

# Bibliotecas
pip install allure-pytest allure-pytest-bdd

# Gerando o resultado do teste
pytest -p no:allure_pytest --alluredir=allure-bdd-results

5. Automação de Testes com BDD

Relatório com Allure Report

Publicar resultado de teste com Allure via API, pode-se utilizar o script abaixo ou algum presente neste endereço: https://github.com/fescobar/allure-docker-service/tree/master/allure-docker-api-usage

import os, requests, json, base64

# This directory is where you have all your results locally, generally named as `allure-results`
allure_results_directory = '/allure-results2'
# This url is where the Allure container is deployed. We are using localhost as example
allure_server = 'http://localhost:5050'
# Project ID according to existent projects in your Allure container -
# Check endpoint for project creation >> `[POST]/projects`
project_id = 'default'
# project_id = 'my-project-id'


# current_directory = os.path.dirname(os.path.realpath(__file__)) - Caso arquivo na raiz do projeto
current_directory = os.path.abspath(r"..")
results_directory = current_directory + allure_results_directory
print('RESULTS DIRECTORY PATH: ' + results_directory)

files = os.listdir(results_directory)

print('FILES:')
results = []
for file in files:
    result = {}

    file_path = results_directory + "/" + file
    print(file_path)

    if os.path.isfile(file_path):
        try:
            with open(file_path, "rb") as f:
                content = f.read()
                if content.strip():
                    b64_content = base64.b64encode(content)
                    result['file_name'] = file
                    result['content_base64'] = b64_content.decode('UTF-8')
                    results.append(result)
                else:
                    print('Empty File skipped: ' + file_path)
        finally :
            f.close()
    else:
        print('Directory skipped: ' + file_path)

headers = {'Content-type': 'application/json'}
request_body = {
    "results": results
}
json_request_body = json.dumps(request_body)

ssl_verification = True

print("------------------SEND-RESULTS------------------")
response = requests.post(allure_server + '/allure-docker-service/send-results?project_id=' + project_id, headers=headers, data=json_request_body, verify=ssl_verification)
print("STATUS CODE:")
print(response.status_code)
print("RESPONSE:")
json_response_body = json.loads(response.content)
json_prettier_response_body = json.dumps(json_response_body, indent=4, sort_keys=True)
print(json_prettier_response_body)

5. Automação de Testes com BDD

Relatório com Allure Report

Referências

Referências

Thanks!

vanilton18@gmail.com

Vanilton Pinheiro

BDD

By Vanilton Pinheiro

BDD

O curso de Desenvolvimento Guiado por Comportamento (BDD) é projetado para capacitar profissionais de desenvolvimento de software a adotar práticas colaborativas e centradas no cliente para criar software de alta qualidade. BDD é uma abordagem que integra desenvolvimento ágil, automação de testes e colaboração entre desenvolvedores, testadores e partes interessadas.

  • 84