Quem me conhece sabe que minhas pesquisas terminam sendo um pouco "exageradas" demais, porém preciso entender o que incentivou a criação e como aplicar em meu dia a dia como desenvolvedor e integrante de um time.
O princípio
Tudo começou com uma pessoa muito importante Dan North - criador do BDD. Na época, ensinava práticas ágeis aplicando o TDD e os mesmos questionamentos apareciam em diferentes contextos ao aplicar a metodologia.Para quem não conhece o TDD, farei uma introdução rápida sobre o assunto, mas se quiser entender um pouco mais a fundo, recomendo ler o artigo que escrevi - Why? What? How? The Importance of Test.
TDD
Para quem não conhece o TDD ou Test Driven Development, ele é uma metodologia de desenvolvimento em que possui um ciclo bem definido: |
| TDD |
São três passos: escrever teste, falhar e refatorar o código. Tendo como foco uma boa cobertura do código. Existem ótimos artigos relacionados a metodologia e como esse não é o nosso foco, não irei aprofundar.
BDD, como tudo começou
Quando Dan North utilizou uma ferramenta chamada agiledox em que removia a palavra test dos códigos de testes e gerava algo mais parecido como um texto/documentação, tendo como resultado:A ferramenta gerava um documento como citado no código acima:
SchoolDaria para utilizar o texto extraído do código como uma documentação do programa, desde que os nomes dos métodos seguissem a linguagem de domínio do negócio, somente assim faria sentido para todos os integrantes do time: gerente, qa, po…
- Find student by name
Nesse exato momento, Dan North percebeu que quando o time "padroniza" o vocabulário, ou seja, seleciona as palavras utilizadas durante todas as etapas de desenvolvimento, era possível construir um documento dinâmico, apenas extraindo pontos importantes dos testes e se tornaria uma documentação compreendida por qualquer integrante do time e/ou empresa que possuísse o entendimento dos vocabulários utilizados.
Algumas sugestões foram surgindo com a evolução do que conhecemos como BDD e tornaram-se características:
- Os métodos de testes deveriam começar com o termo should.
- Declarar o método do teste com o comportamento esperado.
- Envolvimento dos valores de negócios na criação dos testes. Incluindo novas pessoas no processo de criação - steakholders.
- Utilização dos termos: Given, When e Then nos critérios de aceitação nas User Stories.
- Documentação dinâmica, pois é gerada através dos testes escritos.
O BDD assim como a metodologia Agile incentiva a conversa/diálogo entre os envolvidos, visto que o alinhamento do time é de extrema importância desde as definições até as entregas constantes.
Referências:
- Introducing BDD - https://dannorth.net/introducing-bdd/
- Definitions - https://www.agilealliance.org/glossary/gwt/#q=~(filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'given*20when*20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
- Por que o BDD pode salvar o Agile? - https://www.infoq.com/br/news/2015/07/bdd-save-agile
