Compreendendo o Behaviour Driven Development - BDD

Quando comecei a estudar sobre desenvolvimento de testes, o que mais encontrei de artigos na internet foram relacionados a TDD e BDD. Recentemente, comecei a pesquisar um pouco sobre o famoso Behaviour Driven Development (BDD).

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:

	class SchoolTest: XCTest {
	func testFindStudentByName() { }
	}
	//School
	//- Find student by name
	//...

view raw schoolTest.swift hosted with ❤ by GitHub

A ferramenta gerava um documento como citado no código acima:

School
- Find student by name

Daria 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…

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