Behavior
Driven Development (BDD) ou ainda uma tradução livre Desenvolvimento Guiado por
Comportamento é uma técnica de desenvolvimento Ágil que encoraja colaboração
entre desenvolvedores, setores de qualidade e pessoas não técnicas ou de
negócios num projeto de software. Foi originalmente concebido em 2003, por Dan
North [1]como
uma resposta à TDD, e tem se expandido bastante nos últimos anos (Behavior Driven Development, 2012) . No
BDD, os testes de aceitação são descritos em linguagens naturais próximas do
domínio do negócio usando DSL. Para estes testes de aceitação são usadas DSTL e
se estes possuírem formalidade suficiente podem ser interpretados e executados
por uma ferramenta especializada (CAETANO, 2012) . Os testes descritos em linguagem
natural são interpretados por ferramentas especializadas que, por sua vez,
exercitam o código/API do sistema para demonstrar se o comportamento foi
atendido.
O BDD pode ser visto como uma evolução da
técnica de programação TDD [ (AL., 2009) , e compartilha com
essa técnica a característica principal de se escrever testes antes de escrever
a implementação do que está sendo testado, para então desenvolvê-la até que o
teste passe. (RIMMER, 2010) mostra que outra forma de se ver o BDD é
como uma nova compreensão sobre o processo de TDD que estabelece que o teste
não é o ponto central real da técnica, mas sim a descoberta e compreensão,
através da definição dos testes, do comportamento que está se querendo obter
com um código. O processo de BDD incrementa o TDD de forma a resolver algumas
questões em aberto com as seguintes práticas: cada funcionalidade deve ser
claramente compreendida por ambas partes (desenvolvedores e clientes), para
isso se deve usar uma linguagem para os casos de teste compreensível a ambas
partes, uma vez que os casos de teste são na realidade especificações de
comportamento; cada funcionalidade deve possuir um valor claro e verificável
para o negócio, de modo a priorizar o mais importante e evitar o que pode não
vir a ser necessário; deve-se planejar a frente o mínimo possível, escrevendo
testes para o menor e mais prioritário subconjunto de funcionalidades possível
e o desenvolvendo antes de adicionar mais funcionalidades (AL., 2009) .
O foco
em BDD é a linguagem e interações usadas no processo de desenvolvimento de software.
O BDD propicia o uso da língua nativa, a linguagem natural, em combinação com a
linguagem ubíqua (usada no processo de desenvolvimento de software) permitindo
que os desenvolvedores foquem em por que o código deve ser criado, ao invés de
detalhes técnicos minimizando assim, traduções entre linguagem técnica na qual
o código é escrito e outras linguagens de domínio, usuários, clientes, gerência
do projeto, etc. (NORTH, 2006) .
As
práticas de BDD incluem:
●
Envolver
as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora pra Dentro)
●
Usar
exemplos para descrever o comportamento de uma aplicação ou unidades de código
●
Automatizar
os exemplos para prover um feedback
rápido e testes de regressão
● Usar
deve (should em inglês) 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 [2](mocks, stubs, fakes, dummies, spies)
para auxiliar na colaboração entre módulos e códigos que ainda não foram
escritos
BDD é
guiado pelos valores de negócios; que é o benefício trazido para o negócio no
qual a aplicação está sendo produzida. A única maneira na qual o benefício pode
ser percebido é através de interfaces de usuário para a aplicação, comumente
(mas nem sempre) a interface gráfica de usuário. Da mesma maneira, cada trecho
de código, começando com a interface de usuário, pode ser considerado como
sendo um cliente de outros módulos de código no qual a interface é utilizada.
Cada elemento de código provê algum comportamento, o qual em colaboração com
outros elementos provê o comportamento da aplicação. A primeira parte de código
de produção que os desenvolvedores que usam BDD implementam é a interface de
usuário, pois dessa maneira os desenvolvedores podem se beneficiar com um
feedback rápido para saber se a interface está adequada ou não. Através de
código, e usando princípios de design e refatoração, desenvolvedores descobrem
colaboradores para a interface de usuário, e posteriormente para cada unidade
de código. Isso os ajuda a aderirem o princípio de YAGNI, desde que cada trecho
de código de produção é requerido pelos negócios ou por outro trecho de código
já escrito (Behavior Driven Development, 2012) .
Devido
ao impacto da aplicação de BDD no projeto como um todo ele se tornou uma
metodologia ágil de segunda geração. (Primeira geração, Scrum, XP. Segunda
geração BDD). Segundo (CHELIMSKY, ASTELS, et al., 2010) o desenvolvimento
guiado por comportamento se baseia em três princípios básicos:
● O bastante é o bastante: Planejamento
antecipado, análise, e design são atividades que possuem um retorno
decrescente. Não deve-se fazer menos do que o necessário para iniciar o
projeto, porém, mais do que isso é desperdício de esforço. Isso também se aplica
à automação do processo. Ter um processo de implantação do sistema e testes
automatizados é importante, mas deve-se evitar automatizar tudo.
● Entregar valor aos stakeholders: Se uma atividade não está entregando valor ou
melhorando a capacidade de entregar valor, então não se deve executá-la e
deve-se focar em outra atividade.
● Tudo é comportamento: Não importa se ao
nível de código, à nível de aplicação, ou além, pode-se utilizar o mesmo
pensamento e construção linguística para quaisquer níveis de granularidade.
Defensores
de BDD alegam que o uso de "deve" (should) e "garantirQue" (ensureThat) em exemplos de BDD incentivam os desenvolvedores a
questionarem se as responsabilidade que eles estão atribuindo aos seus objetos
são apropriados, ou se elas podem ser delegadas ou movidas inteiramente para
outros objetos. Um objeto que é mais simples que o código de colaboração e
provê a mesma interface, porém com um comportamento mais previsível, pode ser
injetado no código que precisa dele, e os exemplos de comportamento do código
podem ser escrito usando estes objetos ao invés da versão de produção.
A
palavra-chave para este tipo de técnica é "especificação executável”
baseada no comportamento da aplicação. Especificações executáveis têm muito
mais chance de não serem abandonas, já escrevê-las, ao contrário de escrever
estática não executável e tradicional documentação, torna-se efetivamente parte
de todo o processo de desenvolvimento. Executando estas especificações é possível
visualizar instantaneamente o que realmente o software em questão faz, enquanto
no momento em que se inspeciona o código fonte é revelado somente o que este
supostamente deveria realizar. Trazendo á tona um benefício desta prática, gerando
para uma equipe praticante uma maior confiança em relação ao trabalho que está
sendo desenvolvido