BDD – Behavior Driven Development

BDD está ficando mais conhecido ultimamente e muitas pessoas estão adotando a prática no dia a dia de desenvolvimento. Mesmo assim BDD é tão antigo quanto o próprio TDD (Test Driven Development).
BDD nada mais é do que trazer ao código, e principalmente ao código que testa os casos de uso da aplicação, um pouco mais da lógica de negócio e do problema que está sendo resolvido no nível do usuário.

Melhorando a comunicação

Quando escrevemos algum teste unitário, normalmente damos um nome ao teste para que possamos entender os resultados quando gerarmos um relatório após a execução dos mesmos. Também damos nomes que façam sentido, para facilitar a comunicação da equipe de desenvolvimento, pois se outra pessoa da equipe precisar dar manutenção no teste, torna mais fácil a compreensão do que o teste está encarregado de testar sem que seja necessário ler muitas linhas de código.


Nos tempos atuais falamos bastante de aumentar a integração da equipe com o cliente ou a área que entende do negócio da aplicação. Também falamos em uma maior colaboração de ambas as partes no desenvolvimento de software. Para quebrar essa barreira que existe entre desenvolvimento e análise, algumas equipes empregam uma programação mais voltada a resolver os casos de uso propostos, ao invés de resolver problemas de baixo nível e compor uma aplicação final.


BDD prega que o problema que será resolvido deve estar bem claro para a parte quem entende do negócio (chamarei de cliente, mesmo que algumas vezes não seja necessariamente um cliente), e quem desenvolve a aplicação em si. Para isso são escritos casos de testes baseados nos casos de uso do sistema, e tais casos de teste usam uma linguagem comum para ambas as partes.


Como normalmente o cliente não é técnico, fica muito difícil se comunicar com ele via testes unitários em código, e fica mais difícil ainda que o cliente colabore com a melhoria e a escrita de tais testes. Porém, os testes unitários e automatizados são a melhor ferramenta do desenvolvedor para testar a aplicação e garantir que a equipe mantenha o código funcionando.


Para suportar ambas as necessidades, e implantar o BDD de fato, uma das soluções é associar o problema de cada caso de uso, a um teste unitário que irá se certificar que aquele caso de uso está sendo corretamente executado.


Por exemplo, em java podemos dar nomes a nossas classes de teste de acordo com o caso de uso que aquele teste se refere. E podemos também nomear os métodos como a execução específica daquele caso de uso:


[cc_java]

public class TesteDeCadastroDeUsuario {

@Test
public void testeDeCadastrarNovoUsuario() {

// … cadastra o usuário

Assert.assertTrue(“Usuário novo não foi cadastrado corretamente, ”
+ “pois o nome está inválido.”,
nomeUsuarioValido());

}

}

[/cc_java]


Dessa forma quando o cliente ver o resultado dos testes e perceber que este teste falhou, ao invés de ler algo como “O serviço de usuário voltou null.”, ele conseguirá ler “No teste de cadastro de usuário, ao testar que um usuário novo está sendo cadastrado, o teste falhou pois o usuário não possui um nome válido, logo não foi cadastrado.”


Parece pouca coisa, mas para o cliente é um informação muito importante nas discussões sobre prioridade de correção de bugs e melhorias do sistema. Isso porque fica claro para o cliente quando o desenvolvedor descreve o teste exato que falhou e o cliente sabe exatamente a qual caso de teste se refere e qual o problema que está sendo resolvido. Não é informação pertinente ao cliente como que tecnicamente se corrige o problema e como que o sistema está implementado para que o erro ocorre-se, esse é o papel do desenvolvedor.

Simples e Efetivo, mas não é a Silver Bullet

Existem muitos frameworks para facilitar a empregação do BDD. Vimos aqui que mais do que um framework, BDD é uma cultura e pode ser empregado sem o uso de qualquer ferramenta, pois o importante é manter a comunicação entre os níveis técnicos diferente na mesma equipe.


Muitos correm atrás da implantação do BDD nos projetos com a esperança de que os problemas na resolução de bugs e na comunicação da equipe serão resolvidos. Isso não é verdade e seu projeto irá dar tão certo quanto ele daria antes da adoção de BDD. BDD é um mudança de comportamento na equipe onde todos devem estar empenhados na causa de melhorar a comunicação, e tentar entender os problemas de verdade que o sistema se propõe a resolver.


A mudança de comportamento tem que partir do lado do cliente também, pois é necessário a compreensão de que os erros que estão claros para ele agora, não surgiram do nada. Na verdade eles sempre estiveram presentes no sistema, só que protegidos pela barreira que impedia a comunicação entre de desenvolvimento e análise.


Espero ter sido claro, qualquer opinião sobre o assunto será bem vinda.


Por @Gust4v0_H4xx0r