Tableless

Busca Menu

Introdução ao Behavior Driven Development

Seja o primeiro a comentar por

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.

Publicado no dia