Introdução ao Behavior Driven Development

Hoje em dia, se quisermos escrever um bom software. Nossos programadores devem ser especialistas na regra de domínio de nossa aplicação. Não mas...

por Jefersson Nathan 21/02/2014 ~ 2 min. / 338 palavras

O BDD (Behavior Driven Development ou Desenvolvimento guiado por comportamento), é uma resposta ao TDD, criado em 2003, por Dan North, e tem se expandido bastante nos últimos anos. Seu foco é obter um código testado a partir de um conjunto de cenários que descrevem como a aplicação ou unidade de código deverá se comportar em determinada situação.

As práticas de BDD incluem:

  • Envolver as partes interessadas no processo através de Outside-in Development
  • Usar linguagem ubíqua para descrever o comportamento de uma aplicação
  • Automatizar os exemplos para provê um feedback rápido e testes de regressão
  • Usar SHOULD na hora de descrever o comportamento de software para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas
  • Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos

E…

O grande lance do BDD, é que nos trabalhamos com comportamentos de uma maneira que

qualquer pessoa possa entender ou escrever novos testes. Baseado no que espera que

a aplicação executa o aferir uma ação específica.

Qual a vantagem disso? O especialista do domínio pode escrever testes.

O gerente de projetos pode escrever testes. o PO pode escrever testes baseados

no que ele espera da aplicação. O padeiro da esquina pode escrever testes

também. Qualquer um pode descrever o que espera da aplicação sem a necessidade

de ter habilidades de um programador.

Cenários

Cada cenário descreve uma ação que será aferida e testada. Eles devem conter

passos lógicos e simple de como obter um resultado específico a partir de uma sequência

de ações.

Exemplo:

Cenário 1: Quantidade de items no estoque

  • Dado que há 5 items no estoque
  • E um cliente comprou 2 items do estoque
  • Então quando contar os items restantes no estoque
  • Terei 3 items

Como podemos perceber, desenvolvedores podem se concentrar exclusivamente nas razões pelas quais o código deve ser criado, e não em detalhes técnicos, além de minimizar traduções entre a linguagem técnica na qual o código é escrito e outras linguagens de domínio.