Como escrever um bom BDD?

No artigo anterior, BDD – Vantagens e desvantagens no uso em automação de testes,  tivemos a visão das vantagens e desvantagens do uso de BDD para escrita de testes automatizados e agora vamos falar com mais detalhes sobre a escrita do BDD.

O BDD (Behavior Driven Development) propõe uma linguagem única para minimizar a falta de comunicação e garantir que todos – negócio, desenvolvedores, testadores, analistas e gerentes – usem os mesmos termos e fiquem na ‘mesma página’.

A escrita do BDD se baseia na descrição de cenários de teste de uma Feature. Estes cenários apresentam o comportamento esperado e são estruturados seguindo o padrão Contexto-Ação-Resultado escritos em um formato especial chamado Gherkin. Como o Gherkin é estrutural, serve tanto como especificação quanto como entrada em testes automatizados, daí o nome “Especificações Executáveis”.

 

Estrutura Gherkin

O Gherkin está disponível em vários idiomas, permitindo você escrever usando as palavras chave de um idioma específico. Qualquer linguagem diferente do inglês (en) precisa ser explicitada com um comentário #language: <idioma> no início de seu arquivo *.feature.

A estrutura é composta pelas seguintes palavras chave e caracteres especiais padrões:

  • Feature
  • Scenario
  • Background
  • Given, When, Then, And, But
  • Scenario Outline
  • Examples
  • “”” (Doc Strings)
  • | (Data Tables)
  • @ (Tags)
  • # (Comments)
  • < > (parâmetros)
  • “ “ (valores)

 

Exemplo de Estrutura

 

Feature: <Texto conciso descrevendo o que é desejado>

As a <ator explícito do negócio>

I want to <obter algum resultado benéfico para o objetivo>

In order to <realizar algo de valor para o negócio>

 

Scenário <Alguma situação do negócio>

Given <uma pré condição>

And <outra pré condição>

When <uma ação realizada pelo ator>

And <outra ação>

Then <um resultado testável é alcançado>

And <outro resultado>

 

Feature

É uma narrativa que descreve o valor do negócio e não é executável. Cada Feature consiste em uma funcionalidade única. A descrição da Feature segue o padrão:

  • As a/an (Como um) <tipo de usuário/papel>
  • I want to (Eu quero) <realizar uma ação>
  • In order to (Para que) <possa atingir um objetivo relacionado ao valor do negócio>

Salvamos uma Feature por arquivo e este deve possuir a extensão *.feature.

 

Scenario

Uma Feature contém uma lista de Scenarios e cada um destes é um exemplo concreto que ilustra uma regra de negócios. Um Scenario deve descrever um comportamento único e para isso utilizamos as palavras chave Given, When, Then, And e But para detalhar os passos.

  • Given (Dado que) <pré-requisitos>
    • Colocar o sistema em um estado conhecido antes do usuário iniciar a interação com o mesmo.
  • When (Quando) <ação>
    • Descrever a ação chave que o usuário executa.
  • Then (Então) <resultado esperado>
    • Verificar/validar a saída do sistema. É o resultado obtido pela execução da cláusula When.

Se houver vários Given/When/Then pode-se usar And (E) ou But (Mas), permitindo uma leitura mais fluente do cenário.

 

Feature: Pesquisar no site do Google

As a usuário

I want to realizar uma pesquisa

In order to encontrar sites do assunto desejado

 

Scenário Pesquisar sobre Base2

Given um web browser está na página do Google

When informo a palavra “Base2”

And solicito a busca

Then os links relacionados a “Base2” são exibidos

 

Scenario Outline

Permite criar cenários parametrizados (como um template) utilizando parâmetros que estão contidos entre < > nos passos do cenário. O parâmetro receberá um valor das linhas da tabela de Examples. O valor muda a cada execução subsequente do Scenario Outline, até que o fim da tabela seja alcançado.

Na tabela de Examples o cabeçalho de cada coluna corresponde a um dos parâmetros ( < > ) informados nos passos. É possível utilizar múltiplas tabelas de Examples:

  • O que permite agrupar diferentes tipos de exemplos;
  • Quando você tem um grande conjunto de exemplos, dividi-lo em várias tabelas pode facilitar o entendimento.

 

Examples

Exibe os dados que serão utilizados na iteração do cenário durante o tempo de execução.

 

Feature: Login

As a usuário do site

I want to realizar login no site

In order to acessar minha conta

 

Scenário Outline Autenticar informando dado inválido

Given acesso a página de login

When informo <usuário> e <senha>

And solicito acesso

Then o sistema deve exibir a mensagem “Usuario e/ou senha inválido!”

 

Examples: senhas inválidas

| usuario | senha |

| ciclano  | 11111|

| beta      | 22222|

 

Examples: usuários inválidos

| usuario   | senha |

| ciclano1  | 12111|

| beta2      | 21222|

 

Background

Permite adicionar algum contexto a todos os cenários de uma funcionalidade.  É como um Scenario sem título, que contém uma série de passos. A diferença ocorre quando ele é executado: o Background será executado antes de cada Scenario (dentro da mesma Feature).

 

Feature: Login

As a usuário do site

I want to realizar login no site

In order to acessar minha conta

 

Background:

Given acesso a página de login

 

Scenário Autenticar informando dado invalido

When informo fulano e senhaAbc

Then o sistema deve exibir a mensagem “Usuario e/ou senha inválido!”

 

Data Table

Permite passar múltiplos parâmetros (um grande conjunto de dados) em um passo.  Não confunda Data Table com Scenario Outline. Eles têm propósitos diferentes:

  • Scenario Outline: declaram diferentes valores múltiplos ao mesmo cenário.
  • Data Table: são usadas para passar um conjunto de dados a um determinado passo.

 

Feature: Pesquisar usuario

As a usuário do site

I want to realizar por usuario cadastrado

In order to visualizar os dados do usuário

 

Scenário Pesquisar usuario existente

Givenpossuo os seguintes usuários no sistema

| Nome    | Usuario       | Email                       |

| João       | joao.silva    | joao@email.com   |

| Maria    | maria.alves |maria@email.com |

When realizo a pesquisa por “João”

Then visualizo os seguintes dados

| Nome    | Usuario       | Email                       |

| João       | joao.silva    | joao@email.com   |

 

Doc String (“””)

É muito útil quando for necessário informar um texto grande. O texto deve ser delimitado por três aspas duplas.

 

Tags (@)

É uma ótima forma de organizar funcionalidades e cenários.  Um Scenario ou Feature pode ter quantas tags forem necessárias, basta separá-las com espaços.

 

Comentários (#)

Para incluir comentários basta utilizar # antes do texto;

 

@exporta_usuario

Feature: Exportar dados de usuariso

As a usuário do site

I want to exportar dados de usuarios

In order to visualizá-los em um arquivo

# Incluir scenario de exportação html,

 

@exporta_usuario_csv

Scenário Exportar dados de usuario csv

Given possuo os seguintes usuários no sistema

| Nome    | Usuario       | Email                       |

| João       | joao.silva    | joao@email.com   |

| Maria    | maria.alves |maria@email.com |

When solicito a exportação

Then visualizo um arquivo com os dados

“””

João;joao.silva;joao@email.com

Maria;maria.alves;maria@email.com

“””

Boas práticas

Agora que sabemos como é a estrutura de um BDD vamos ver algumas boas práticas para facilitar a escrita e entendimento dos cenários:

  • Não utilizar referência a itens de implementação (ex.: nomes de campos, IDs de campos, queries SQL etc.)
  • A palavra “ou” não deve ser usada. Se a palavra “ou” é usada em algum momento é sinal que o cenário pode ser quebrado em um ou mais cenários.
  • Em features com uso de Background a palavra Given não deve ser utilizada. Os cenários serão iniciados com And ou com When.
  • Utilizar o mesmo nome para a feature e seu respectivo arquivo. Se o nome da feature possuir acento ou espaço, converter o espaço por “_” e remover o acento ao nomear o arquivo ou utilizar a técnica CamelCase. Ex.: feature “Cadastro de Usuário”; arquivo “Cadastro_de_usuario” ou “CadastroDeUsuario”;
  • Nome da feature e do cenário deve conter alguma característica que os identifique de forma única e que façam sentido. O nome deve começar com letra maiúscula.
  • Um cenário deve testar um comportamento único.
  • Os cenários não devem conter detalhes técnicos. Foque no “o quê” e evite o “como”.
  • Faça cenários mais declarativos (enxuto e conciso) e menos imperativos (detalhados).
  • Evite dependências entre cenários.
  • Scenarios não devem usar dados que podem mudar com frequência (ex.: a cada restore do banco de dados)
  • Usar a técnica CamelCase nas variáveis informadas nos passos, na seção Examples ou na DataTable. Ex: dataNascimento.
  • Sentenças após as palavras chaves Given, When e Then devem começar com letra minúscula.
  • Utilizar uma ou mais tags na feature para identificar os sistemas manipulados pelos cenários/features.
  • Se a tag aplica-se a todos os cenários ela deve ser vinculada à feature. Já se aplicar a apenas um cenário, ela deve ser vinculada ao cenário.
  • Adote um conjunto padrão de tags e evite duplicar (ex.: duas tags com o mesmo sentido).
  • Escreva tags em minúsculo e use hifens (“-“) para separar as palavras. Ex: @cadastro-usuario
  • As tags devem ficar na linha anterior às palavras reservadas “Scenario“, “Scenario Outline” ou “Feature“.

Agora é hora de por a mão na massa e praticar! Os primeiros cenários podem ser difíceis de escrever até você absorver a ideia da estrutura do BDD, mas os próximos fluirão melhor pode ter certeza.

 

Autora: Helen Flávia Brito de Assis

Arquiteta de Testes na Base2

2 thoughts on “Como escrever um bom BDD?

  1. Parabéns, excelente! Eu me chamo Carla, sou analista de requisitos e estou começando os estudos na área de testes, no momento estou desempregada e estudando bastante. Você tem algum curso online, ou no youtube?

    1. Olá Carla, muito obrigado pelo seu recado! Não temos canal no youtube com cursos, mas toda semana divulgamos novos conteúdos relacionados a qualidade de software.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *