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