Algumas observações sobre BDD
Ultimamente estive pesquisando sobre o assunto BDD (Behaviour-Driven Development) e também praticado com alguns exemplos reais, através disso devo dizer que consegui tirar algumas conclusões bem interessantes sobre o assunto, nas quais gostaria de expor aqui. Vamos a elas:
BDD ajuda você, BDD ajuda seu cliente
Um ponto que pude observar, é que usando BDD a possibilidade de um cliente participar de um projeto é imensa, mesmo que você não use alguma metodologia ágil (falarei sobre isso a seguir). E por que ele pode participar? É simples, pois é ele quem pode escrever os testes. Se ainda assim não for o seu cliente o responsável por escrever os testes, será ele quem irá validá-los, ou seja, você pode escrever os testes e pedir para que ele aprove ou não. Isso é muito importante, pois nesse caso os testes em BDD seriam o contrato entre você o seu cliente, entre o que você está entregando e o que ele está esperando.
BDD favorece o sucesso do uso de metodologias ágeis
Sem dúvida nenhuma um dos pontos fortes do uso de BDD é que suas características se encaixam muito bem em equipes que fazem o uso de metodologia ágil. E são vários pontos que favorecem.
Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável (PO) por criar as estórias (ítens do backlog) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.
Os artefatos que constituem BDD são muito, mais muito semelhantes aos artefatos presentes em ágil.
Em BDD se usa estórias e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requisitos das metodologias ágeis.
Favorece a escrita de testes antes da implementação
Uma boa prática na criação de testes, independente se você usa BDD ou TDD, é que os testes sejam criados antes de tudo. Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los. Já com BDD, a primeira coisa que você precisa ter em mãos antes de implementar os testes são as estórias e os cenários, não tem como fugir disso, o que torna muito mais nítido que em primeiro lugar vem os testes e depois as implementações.
Torna mais nítido o que sua aplicação deve fazer
Com BDD é muito mais fácil isolar as funcionalidade da sua aplicação, já que o que é testado é exatamente isso, dessa forma fica fácil identificar os componentes que envolvem determinada funcionalidade, torna mais nítido qual é o papel daquela funcionalidade, além do que consegue dar um sentido melhor para a sua aplicação de maneira geral.
Com BDD, você consegue ainda uma visão de workflow da sua aplicação, ou seja, uma visão macro, o que favorece dar manutenção a mesma. Percebo também, que BDD favorece um bom design de código, evitando assim problemas de desenvolvimento como códigos com alto-acoplamento.
Torna os testes mais humanos
A essência do BDD são os cenários e não parte isoladas da aplicação e essa maneira de lidar com testes favorece o entendimento por parte de nós, humanos.
Testes de interface com o Selenium, tornam-se mais compreensíveis num contexto que envolva BDD, como em um teste de login, por exemplo.
Conclusão
Na minha opinião, está mais do que clara a vantagem no uso de BDD, entretanto ele não substitui o uso de TDD, pois a abordagem de ambas são diferentes e complementares.
No próximo tópico, irei mostrar um cenário de testes com o framework JBehave, um framework BDD para Java.
Mais sobre o assunto
The difference between TDD and BDD
Se você gostou desse tópico, por favor considere deixar um comentário ou se inscreva no feed e tenha no futuro todos os tópicos entregues diretamente no seu agregador.
Oi Marcus, gostei do texto, mas tenho que discordar da citação abaixo:
“Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los.”
Se a pessoa está fazendo isso, podemos dizer que ele usa testes automatizados, mas não TDD. O ciclo do TDD é bem claro e quem não o segue não está “guiando seu desenvolvimento por testes”.
Abraços.
Fala Celso, tudo bom?
Antes de mais nada, obrigado pela sua visita e pelo seu elogio!
Quanto ao seu comentário, concordo plenamente, mas a minha citação foi justamente para dizer, que no começo as pessoas não tendem a programar orientado a tstes (TDD), justamente por não entenderem o propósito dessa abordagem. De fato se a pessoa não desenvolve dessa maneira, com certeza ela não está usando TDD, por mais que ela possa achar isso.
Acredito que a maioria das pessoas fazem isso, justamente por terem dificuldade em abstrair a questão do teste antes mesmo da funcionalidade e de fato isso no TDD é um pouco esquisito de entender no seu começo. Eu, particularmente acho o conceito do BDD mais fácil de absorver do que TDD, quando um leigo entra nesse mundo de testes.
Apesar de ler este texto só agora ele foi muito válido para mim. Estou fazendo uma especialização em desenvolvimento ágil e me familiariazando com BDD agora e deu pra entender muitas coisas com teu post.
Parabéns, cara!
Vou escrever algo sobre as vantagens do BDD em times ágeis no meu blog.
Um abraço!