BDD

Autor: Laerte Guedes

AIT-PROEG

BDD: Conceito

BDD (Behavior Driven Development) : Tem seu foco principal no comportamento do software, ou seja, no que será entregue, de modo a reduzir a distância entre o negócio e a tecnologia. É considerado por seus adeptos como uma evolução do TDD, e é uma mistura do TDD (Test Driven Development) e DDD (Domain Drive Design).

TDD: Conceito

TDD (Test Driven Development): Consiste em escreve um teste antes de criar determinada funcionalidade, executar este teste e vê-lo parar, codificar o suficiente para ver o teste passar e depois refatorar o código. É bastante utilizado no mercado e no geral, aumenta a qualidade do software.

DDD: Conceito

Traduzindo significa “Projeto Orientado a Domínio” e basicamente descreve padrões de desenvolvimento de software, com ênfase em boas práticas de programação, integração entre código e negócio e baixo acoplamento entre classes.

BDD: Princípios Fundamentais

Negócio e Tecnologia deveriam “falar” sobre um sistema.

Qualquer sistema deveria ter um valor identificável e verificável para o “negócio”.

Análise, design e planejamento precoce tem, sempre, retorno questionável.

BDD: Fluxograma

BDD - Processo

BDD integra, negócio e TI. Negócio: Compete a este a

definição de Features (em alto nível, as principais características do sistema), cenários (ações e resultados esperados) e passos (interações entre usuário ou sistema e um determinados resultado esperado).

BDD - Processo

TI: Definição das etapas (correspondências, usando teste, podendo ser estes de unidade e etapas definidas pelo negócio) e código (codificação integrada com o negócio).

BDD - Gherkin A adoção efetiva do BDD implica na

utilização de uma vocabulário consistente por parte do “negócio”. Trata-se do Gherkin.

Cada cenário corresponde a uma lista de etapas.

Eles são descritos em arquivos texto simples, escritos em “qualquer” idioma obedecendo algumas regras simples de sintaxe.

O nome desse “conjunto de regras simples” é Gherkin.

BDD - Gherkim

BDD - Vantagens

Testes antes da implementação aumentam a qualidade do produto.

Definição de cenário e etapas deixa muito mais nítido o que deve ser feito.

Torna os testes mais humanos, por os cenário serem “não abstratos”.

Maior aproximação com o P.O.

Fontes

http://www.urubatan.com.br/introduzindo-bdd/

http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/

http://www.marcuscavalcanti.net/blog/2010/01/07/algumas-observacoes-sobre-bdd/

Obrigado!