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
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?
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.