Este artigo introduz a prática ágil conhecida como Behaviour-Driven Development juntamente com alguns exemplos práticos de um software escritos no SpecFlow, um framework open-source escrito em .Net para auxiliar na aplicação do BDD.
Para que serve
É utilizado no desenvolvimento para gerar um modelo de classes coeso e garantir a segurança durante a manutenção do software com o passar do tempo. Além disso, também pode ser utilizado para facilitar a comunicação entre os desenvolvedores e os especialistas de negócio.
Em que situação o tema é útil
Esta técnica pode ser utilizada em qualquer projeto .Net, seja ele pequeno ou grande, simples ou complexo. Cabe aos responsáveis técnicos avaliarem a viabilidade da técnica e utilizarem o melhor dela em seu dia a dia.
BDD
O Behaviour-Driven Development é recente e tem como objetivo garantir funcionalidades em um sistema através da especificação de cenários. Estes cenários são escritos em uma linguagem natural, o que possibilita que qualquer pessoa possa ler e entender. Será mostrado na prática, através de um exemplo de uma lanchonete, como utilizar o SpecFlow para escrever cenários em arquivos estáticos e transformá-los em testes automatizados a fim de que se possa validar o funcionamento do sistema.
Desenvolver um software que siga todos os requisitos desejados tais como, robustez, facilidade de manutenção, confiança e reusabilidade sempre foi um grande desafio. Nos últimos anos têm surgido algumas práticas, técnicas e métodos que visam mudar a forma com que a programação de software é executada a fim de melhorar a qualidade do código que escrevemos e, consequentemente, entregar um software mais confiável para os clientes. Dentre estas práticas, uma das que mais está fazendo barulho atualmente é o Test-Driven Development (TDD). Foi formulado há pouco mais de 10 anos e tem sido bastante elogiado por quem o utiliza. Apesar de ainda não ser realidade na maioria das equipes, tem sido bastante difundido nos últimos anos assim como outras práticas como Refatoração, Programação em Par (Pair Programming), Design Incremental entre outras.
Um pouco sobre TDD
O TDD é uma técnica de desenvolvimento ágil cujo objetivo é desenvolver um software guiado por diversos casos de testes que validam alguma determinada função do software. O ciclo de implementação dele segue três simples passos. Primeiro cria-se um caso de teste que vai falhar, em seguida o fazemos passar escrevendo o mínimo de código de produção necessário. Feito isso, vem o período de refatoração onde o código é organizado para deixá-lo mais legível, aumentar o desempenho, remover bad smells (maus cheiros) entre outras mudanças.
Programadores que já praticaram isso alguma vez sabem como é vantajoso poder, a qualquer momento, fazer uma verificação completa de toda a aplicação com apenas um comando e no final ainda ter um relatório com o resultado dos testes. Aqueles testes demorados que antes eram feitos manualmente entrando tela por tela do sistema e verificando se ele estava se comportando da forma esperada agora são reduzidos drasticamente, podemos delegar esta tarefa para o computador e começar algo novo e que trará maior valor agregado ao sistema.
Acontece que isso é apenas uma parcela do TDD, na verdade esse é um dos resultados obtidos pela aplicação dele, mas não foi esta a motivação que levou a sua concepção. TDD é muito mais sobre a construção de um design de software coeso e limpo do que a criação de uma bateria de testes. Esta é a maior confusão de quem está começando a estudar TDD hoje em dia, e um dos maiores fatores para que isto ocorra é seu próprio nome. O prefixo Test leva-nos a dar uma importância muito grande ao teste, até mesmo mais do que às funcionalidades do software em si.
E o BDD, o que é?
Em 2006, Dan North apresentou o Behaviour-Driven Development. Muito se fala atualmente que o BDD nada mais é que o TDD feito de forma correta ou então que é uma resposta ao mau uso do TDD, não há como negar, é muito semelhante, mas também possuem suas diferenças. A mais perceptível é com relação à nomenclatura e linguagem utilizada, ao invés de especificarmos “casos de testes” que irão testar se a aplicação está retornando os resultados esperados, agora temos “cenários” que especificam qual o comportamento esperado do sistema em um determinado contexto. Mais do que apenas verificar, os cenários especificam e garantem quais funções são suportadas pelo sistema em um vocabulário comum.
Para realmente entender como isso tudo funciona são necessários alguns exemplos práticos, o que precisa ser entendido aqui é que o objetivo do BDD é melhorar a comunicação entre todos os stakeholders deixando bem claro como o software se comporta através de cenários escritos em uma linguagem natural.
Todo cenário possui um contexto inicial, um evento, um resultado e faz parte de uma história. A história nada mais é que uma narrativa que serve para dar um motivo à especificação dos cenários. Elas seguem um padrão mais ou menos como este:
Eu, como <papel>, desejo <o que é necessário> para <motivo>.É comum encontramos padrões diferentes, o importante é que o sentido da sentença permaneça o mesmo. Veja a seguir um exemplo concreto:
“Eu, como administrador de uma intranet corporativa, desejo ter a possibilidade de manipular completamente todas as contas de usuários para que eu possa ter controle sobre os acessos. ”Temos aí uma história que possui um valor de negócio, pois foi algo que o próprio cliente solicitou, talvez em outras palavras, mas é exatamente isso que ele está querendo. Neste momento define-se que o que vamos fazer é algo que é importante para ele, de fato. Baseado nesta história, é necessário definir alguns cenários que irão demonstrar o comportamento esperado desta nova funcionalidade. Os cenários possuem o seguinte padrão:
Dado <contexto inicial>
Quando <evento>
Então <resultado>É importante lembrar que após cada um dos passos, pode-se incluir a conjunção “E” a fim de adicionar novos passos, abaixo estão dois cenários de exemplo:
Dado que não existe um usuário chamado ‘maria’
Quando eu criar um usuário chamado ‘maria’ com a senha ‘maria@123’
E eu tentar acessar usando as credenciais ‘maria’ e ‘maria@123’
Então eu devo ser direcionado para a página de boas vindas
Dado que exista um usuário chamado ‘joao’ com o endereço de e-mail joao@exemplo.com.br
Quando eu bloquear este usuário
Então um e-mail de aviso deve ser enviado para joao@exemplo.com.br ... 
