O documento discute como a técnica Behavior-Driven Development (BDD) pode ser usada para criar especificações vivas que servem como documentação formal para desenvolvedores e reduzem o gap entre requisitos, desenvolvimento e testes. O BDD usa cenários para descrever o comportamento desejado do sistema e frameworks como Cucumber para escrever testes em linguagem natural que são executados contra o código. Isso permite integrar requisitos de negócio com o desenvolvimento orientado a testes.

1. DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou
Story - por Kamilla Queiróz
Será que era possível criar uma documentação formal que pudesse servir de base para o
desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que
era possível ter documentações ou especificações vivas, ou seja, on
consistente com o código e é entregue como evidência de software funcionando ?
Introdução
É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de
documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará
ultrapassado, podemos desenvolver espec
entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do
desenvolvimento se mantenha na entrega de valor
Uma possível solução para essas questões, pode ser o uso de uma técnica cha
nada mais é que uma técnica ágil de desenvolvimento, também conhecida como
Specification By Example, que visa a integração entre regras de negócio com linguagem de
programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de
desenvolvimento de software.
BDD
O Behaviour-Driven Development
ainda sendo possível pensá-
desenvolvimento orientado a testes
desenvolvimento, sendo escrito primeiro o testes para somente depois o código
conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento
visando testes.
DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou
Será que era possível criar uma documentação formal que pudesse servir de base para o
desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que
era possível ter documentações ou especificações vivas, ou seja, onde é ela mantida
consistente com o código e é entregue como evidência de software funcionando ?
É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de
documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará
ultrapassado, podemos desenvolver especificações vivas, que aliam e diminuem a distância
entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do
desenvolvimento se mantenha na entrega de valor
Uma possível solução para essas questões, pode ser o uso de uma técnica cha
nada mais é que uma técnica ágil de desenvolvimento, também conhecida como
, que visa a integração entre regras de negócio com linguagem de
programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de
desenvolvimento de software.
Fig #1 - como visto ficando a cargo do negócio
definições de Features / Cenários / Passos/Etapas
(steps) e para a tecnologia Definições para etapas (Step
definitions) / Código / Biblioteca de automação
Driven Development, tem seu foco no comportamento do software, também
-lo como um aperfeiçoamento sendo a próxima milha para o
desenvolvimento orientado a testes - uma vez que os testes ainda orientam o
sendo escrito primeiro o testes para somente depois o código
conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento
DevQA: Especificações Vivas: Como criar testes compiláveis para o seu User Case ou User
Será que era possível criar uma documentação formal que pudesse servir de base para o
desenvolvedor, e assim diminuir o gap entre requisitos, desenvolvimento e testes ? Será que
de é ela mantida
consistente com o código e é entregue como evidência de software funcionando ?
É possível pensarmos que ao invés de trabalharmos para criar e manter uma série de
documentações estáticas e com custo de manutenção elevado, que gradualmente se tornará
ificações vivas, que aliam e diminuem a distância
entre conhecimento do negócio e a tecnologia, assim colaborando para que o foco do
Uma possível solução para essas questões, pode ser o uso de uma técnica chamada BDD, que
nada mais é que uma técnica ágil de desenvolvimento, também conhecida como
, que visa a integração entre regras de negócio com linguagem de
programação, encorajando a colaboração entre as várias partes envolvidas em um projeto de
como visto ficando a cargo do negócio
definições de Features / Cenários / Passos/Etapas
(steps) e para a tecnologia Definições para etapas (Step
definitions) / Código / Biblioteca de automação
, tem seu foco no comportamento do software, também
sendo a próxima milha para o
uma vez que os testes ainda orientam o
sendo escrito primeiro o testes para somente depois o código - com alguns
conceitos do DDD, focando no comportamento do sistema somado a um desenvolvimento

2. As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente
visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para
usuários de negócio.
Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo
seu foco a linguagem e as interações usadas no proces
“ruídos” na comunicação de forma que todos os interessados
– estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento
inadequado. A “venda da ideia” para BD
por envolver mais gente, seja mais “trabalhoso” de implantar.
Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a
linguagem de negócio usada pelo próprio cliente e pode ser ex
especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que
alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como
cenários para os testes.
Se lembrarmos de quando Dan North
perceber a sugestão para que fosse seguido um padrão de escrita.
Fig. #2 - Modelo sugerido por Dan North
Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá
aos leitores uma ideia de como o sistema irá se com
simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software
é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de
ambos os envolvidos no projeto, técnicos
aspectos do DDD com os conceitos fundamentais do TDD.
BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks
específicos de BDD que têm surgido em diversas linguagens. Um dos
BDD, JBehave, foi criado por Dan North, seguido de um framework em Ruby chamado
RBehave, no qual foi depois incorporado ao projeto
Hellesoy, é um outro exemplo que pode ser usado para testar código Java, .NET e Flex.
Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em
uma linguagem de domínio específico chamada
natural, mas que contém algumas palavras chaves que orientam sua sintaxe:
As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente
visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para
Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo
seu foco a linguagem e as interações usadas no processo de desenvolvimento, minimizando os
“ruídos” na comunicação de forma que todos os interessados – tanto de TI, quanto do negócio
estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento
inadequado. A “venda da ideia” para BDD costuma ser mais fácil do que para TDD. Embora,
por envolver mais gente, seja mais “trabalhoso” de implantar.
Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a
linguagem de negócio usada pelo próprio cliente e pode ser extraída das estórias ou
especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que
alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como
Dan North apresentou este conceito ainda em 2003, é possível
perceber a sugestão para que fosse seguido um padrão de escrita.
Modelo sugerido por Dan North - sendo esse apenas um modelo e não um formato obrigatório.
Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá
aos leitores uma ideia de como o sistema irá se comportar em vários cenários, e não
simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software
é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de
ambos os envolvidos no projeto, técnicos ou especialistas no negócio, através da mistura dos
aspectos do DDD com os conceitos fundamentais do TDD.
BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks
específicos de BDD que têm surgido em diversas linguagens. Um dos primeiros frameworks de
, foi criado por Dan North, seguido de um framework em Ruby chamado
, no qual foi depois incorporado ao projeto RSpec. O Cucumber, escrito por
um outro exemplo que pode ser usado para testar código Java, .NET e Flex.
Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em
uma linguagem de domínio específico chamada Gherkin muito semelhante à linguagem
natural, mas que contém algumas palavras chaves que orientam sua sintaxe:
As especificações criadas quando, utilizado BDD usam a mesma linguagem onipresente como
visto no domínio real, o qual pode ser benéfico tanto para usuários técnicos como para
Assim o BDD se apoia no uso de um vocabulário pequeno e bem específico, nesse ponto sendo
so de desenvolvimento, minimizando os
tanto de TI, quanto do negócio
estejam alinhados, apoiando todos os envolvidos e reduzindo riscos de desenvolvimento
D costuma ser mais fácil do que para TDD. Embora,
Todo o desenvolvimento das especificações são baseadas em cenários, que utilizam a
traída das estórias ou
especificações fornecidas durante o procedimento de levantamento dos requisitos. Sendo que
alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como
apresentou este conceito ainda em 2003, é possível
sendo esse apenas um modelo e não um formato obrigatório.
Dessa forma, a documentação que é produzida quando escrevemos especificações em BDD, dá
portar em vários cenários, e não
simplesmente verificar se os métodos estão retornados os dados corretos, ou seja, o software
é criado baseado em critérios de aceitação. Com isso, podemos atender as necessidades de
ou especialistas no negócio, através da mistura dos
BDD pode ser realizado utilizando frameworks de testes de unidade, ou com frameworks
primeiros frameworks de
, foi criado por Dan North, seguido de um framework em Ruby chamado
, escrito por Aslak
um outro exemplo que pode ser usado para testar código Java, .NET e Flex.
Utilizando o Cucumber, as funcionalidades do sistema são escritas em arquivos de texto e em
muito semelhante à linguagem

3. • Funcionalidade
• Contexto
• Cenário
• Dado
• Quando
• Então
• E
• Mas
• Esquema de cenário
• Exemplos
Desta forma os testes de BDD são compostos, basicamente
funcionalidades - features e por arquivos de definição de passos
funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio
do sistema.
As funcionalidades são descritas e armazenadas em arquivos com extensão
descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter
diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se
comportar em uma determinada situação.
Devemos perceber que os cenários seguem sempre um padrão:
1. Colocam o sistema em um determinado estado;
2. Fazem alguma ação sobre o sistema (provocação);
3. Examinam o novo estado.
Fig #3 - Exemplo de um arquivo de funcionalidade com fluxo simples de login.
Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses
cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele
"quebrando". Depois disso é hora da construção e implementação, onde para cada
funcionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a
funcionar.
Conclusão
Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de
desenvolvimento, e chegando nas áreas de requisitos, teste e qualidad
Desta forma os testes de BDD são compostos, basicamente, por arquivos que especificam as
e por arquivos de definição de passos - steps . Os arquivos com as
funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio
scritas e armazenadas em arquivos com extensão .feature
descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter
diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se
inada situação.
Devemos perceber que os cenários seguem sempre um padrão:
Colocam o sistema em um determinado estado;
Fazem alguma ação sobre o sistema (provocação);
Examinam o novo estado.
Exemplo de um arquivo de funcionalidade com fluxo simples de login.
Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses
cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele
"quebrando". Depois disso é hora da construção e implementação, onde para cada
uncionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a
Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de
desenvolvimento, e chegando nas áreas de requisitos, teste e qualidade.
, por arquivos que especificam as
. Os arquivos com as
funcionalidades são compostos por cenários, que exemplificam uma ou mais regras de negócio
.feature. Cenários
descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conter
diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se
Dado que os cenários estão feitos, podemos agora criar uma ambiente de execução desses
cenários e fazer o primeiro passo do TDD, ou seja, criar meu teste unitário e deixar ele
"quebrando". Depois disso é hora da construção e implementação, onde para cada
uncionalidade criada, um ou mais cenários sejam atendidos, ou seja, meus testes começam a
Com isso, o BDD se torna uma evolução do TDD, saindo do ambiente somente de

4. Vantagens
Para a Engenharia:
• é um teste que evita defeito, não que encontra defeitos;
• torna os testes como requisitos; torna os testes mais elegantes;
• torna os testes mais legíveis e sucintos;
• torna os testes mais simples para pessoas de negócios;
• consome menos tempo para escrever testes;
• é uma documentação executável;
• é tecnicamente um teste de unidade, integração ou sistema, mas com valor de teste
de aceite;
Para a Gestão:
• pode ser usado como ferramenta para mensura o tamanho e progresso do projeto;
• é uma documentação evolutiva;
• é formado por critérios de aceite que representam o valor do produto e não valor de
documentação;
Desvantagens
• é necessário uma boa abstração e uma visão sistêmica para criar os cenários;
• é necessário um especialista de negócio para fazer a duas mãos os cenários;
• refactoring é necessário e comum.
• deve está aliado a um ambiente de integração contínua.
Links Relacionados
The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends
Wikipedia: Behavior-driven development
BDDWiki: BehaviourDrivenDevelopment
Publicado originalmente em O Tapioca: http://www.otapioca.com.br/?p=2574