Desenvolvimento Guiado por Comportamento (Behavior Driven Development - BDD)
Vanilton Pinheiro
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 |
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
Dan trabalhou com David Chelimsky, Aslak Hellesøy e outros para desenvolver RSpec e escrever o livro RSpec Book
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
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
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
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ê
2
Valor entregue
o que será feito?
1.
Jornada
Como será feito?
Exemplos
2.
Identificação do Valor
Por quê será feito?
3.
2. Cenários e Especificações
Amazon.com.br é um(a)...?
2. Cenários e Especificações
2. Cenários e Especificações
- Requisitos (User Stories)
- Documentos
- E-mails
- Reuniões
Linguagem Ubíqua pode ser utilizada:
2. Cenários e Especificações
-
Menos risco de falta de entendimento
-
Comunicação mais rápida e direta
-
Conhecimento do domínio por todos
-
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
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
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
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
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
- 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
- Crie o arquivo de feature cliente.
- Vamos gerar os steps
- 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
- Crie o arquivo de feature cliente
- Gere os steps
- Implemente os steps
- 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
- 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
- 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
- Todo cenário terá uma função de teste que será chamada ao seu final.
- Experimente tirar o prefixo test da função e executar o teste.
Nomeando passos
5. Automação de Testes com BDD
- 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
- Garanta que esteja com o Docker em execução na sua máquina
- Clone o projeto: https://github.com/smokysk/shop-django-rest-framework/tree/develop
- Acesse a pasta do projeto
- 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
Documentação da API: http://127.0.0.1:8000/doc/#operation/auth_login_create
Endpoint para autenticação
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
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
- string
- 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:
- Subir o Server e UI do Allure
- Instalar biblioteca para gerar o resultado allure
- 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
Acessando o resultado
http://localhost:5252/allure-docker-service-ui/projects/default/reports/latest
https://blog.onedaytesting.com.br/gherkin/
https://medium.com/@aparna.gopalakrishnan/https-medium-com-aparna-small-things-about-bdd-a08b8196733
https://en.wikipedia.org/wiki/Outside%E2%80%93in_software_development
https://cucumber.io/docs/bdd/better-gherkin/
https://caroli.org/historias-do-usuario-e-a-construcao-de-produtos-de-sucesso/
Referências
https://medium.com/@daniloflinhares/bdd-behavior-driven-development-2b1d0a8329e3
https://pt.wikipedia.org/wiki/Behavior_Driven_Development
https://cucumber.io/blog/bdd/where_should_you_use_bdd/
https://sol.sbc.org.br/index.php/sbqs/article/view/15231/15075
https://blog.onedaytesting.com.br/gherkin/
https://pytest-bdd.readthedocs.io/en/stable/
https://docs.pytest.org/en/stable/how-to/mark.html
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