O Que é BDD

O que é BDD?

Behavior Driven Development BDD ou ainda uma tradução Desenvolvimento Guiado por Comportamento é uma técnica de desenvolvimento de software cuja amplitude se estende às atividades de levantamento de requisitos, design, documentação e verificação & validação, tratando-as de modo unificado, disciplinado e com foco em qualidade e em entrega rápida de software de valor.

BDD encoraja e fornece um ambiente propício à colaboração entre desenvolvedores, setores de qualidade e pessoal de negócios em um projeto de software.

BDD foi concebida inicialmente por North (2006), tendo recebido um grande número de contribuições de praticantes ao redor do mundo, principalmente de textos publicados em blogs. Chelimsky detalha a técnica no contexto de ferramentas BDD para a linguagem Ruby, sendo provavelmente o maior conjunto de informações sobre BDD disponível atualmente em uma mesma fonte.

O ciclo outside-in

Quando se usa BDD, as atividades necessárias ao desenvolvimento de uma funcionalidade são realizadas segundo um ciclo denominado outside-in. O ciclo recebe este nome devido à sequência que deve ser percorrida, que se inicia dos requisitos e da visão do cliente (outside) até as entranhas dos artefatos de software (in).

Este ciclo pode ser explicado em uma série de passos, adaptados de Chelimsky e comentados:

1. Foco em um cenário

Na terminologia de BDD, um cenário é um exemplo de utilização de uma dada funcionalidade. Uma funcionalidade é algo que o software deve oferecer e que possui um valor bem definido para o cliente. Em BDD, o foco dos desenvolvedores deve estar sempre direcionado a um único cenário de uma única funcionalidade por vez. Isto elimina dispersões e mantém o desenvolvedor concentrado na tarefa a ser realizada.

2. Escreva uma especificação para este cenário

BDD possui um pressuposto central segundo o qual nenhuma funcionalidade, no todo em ou parte, é implementada sem a escrita prévia de uma especificação executável. Assim, antes de qualquer atividade de implementação de uma funcionalidade, deve ser escrita uma especificação, em linguagem natural, de como a funcionalidade deve ser do ponto de vista do cliente.

3. Escreva uma especificação de unidade

Para fazer a especificação do usuário executar com sucesso, é necessário implementar algo, seja uma classe, uma função, uma página HTML. É importante perceber que há aqui uma mudança de nível: a especificação do usuário apenas se preocupa com a parte do software visível externamente, mas nada diz a respeito dos diferentes artefatos em código-fonte que comporão o software. Neste ponto é necessário escrever uma nova especificação, desta vez uma especificação de unidade, que descreve o funcionamento do artefato (classe, função, página, módulo etc.) que precisa ser implementado para cumprir a especificação do usuário.

4. Faça a especificação de unidade passar

Neste momento, o artefato de software deve ser implementado de modo a passar na especificação de unidade. A implementação deve ser a mais simples e mínima possível, apenas o estritamente necessário para fazer a especificação passar. BDD vale lembrar, trabalha orientada ao usuário e à geração de valor para este. Além disto, enquanto código útil é um patrimônio que gera valor, qualquer código criado inutilmente é tempo desperdiçado e, no fim das contas, um fardo, que sem gerar valor algum, aumentará a complexidade geral do software. O uso de técnicas de efetiva garantia de qualidade como BDD, aliado a técnicas modernas de design e boas práticas de programação (MARTIN, 2008; BECK, 2007) tornam desnecessária a obsessão com “estar preparado para as mudanças” que assolou os programadores e designers em tempos idos.

5. Refatore

Conforme o item anterior, em BDD todo código deve ser implementado apenas para satisfazer às especificações atuais, sem maiores preocupações em criar facilidades para acomodação de novos requisitos. Estas preocupações normalmente se expressam por meio de pensamentos como “é melhor fazer desde já esta associação como muitos-para-muitos, pois é muito provável que isto seja necessário no futuro”. É natural que haja este tipo de preocupação, uma vez que é fato conhecido de qualquer desenvolvedor de software que a simplicidade e clareza do design tendem a decair no decorrer do tempo. Assim, mudanças são mais simples de serem aplicadas no início do projeto do que em tempos posteriores. Isto se traduz na famosa curva de Boehm, que mostra que o custo das modificações em um projeto de software sobe exponencialmente no decorrer do tempo (BOEHM, 1981). BDD se utiliza de uma técnica conhecida como refatoracão, que consiste em aperfeiçoar o design interno de um software sem qualquer percepção de mudança sob o ponto de vista dos usuários. Na refatoração, o código que foi implementado apenas com o mínimo necessário para fazer a especificação passar deve agora ser reestruturado de modo a se adequar harmoniosamente ao design preexistente. Quando se usa BDD, não se faz um design prévio detalhado. Ao contrário, o design evolui (BECK e ANDRES, 2004; BAIN, 2008) a cada nova especificação implementada, sendo o papel da refatoração manter o design sempre da forma desejada. A princípio, o