O Test-Driven Development é uma metodologia de desenvolvimento de software para teste primeiro, o que significa que requer a gravação do código de teste antes de escrever o código real que será testado. Nas palavras de Kent Beck:
O estilo aqui é escrever algumas linhas de código, depois um teste que deve ser executado, ou melhor ainda, escrever um teste que não será executado e, em seguida, escrever o código que a fará executar.
Depois de descobrir como escrever um pequeno pedaço de código, agora, em vez de apenas codificar, queremos obter feedback imediato e praticar "codifique um pouco, teste um pouco, codifique um pouco, teste um pouco". Então, escrevemos imediatamente um teste para isso.
Portanto, o TDD é uma metodologia técnica de baixo nível que os programadores usam para produzir um código limpo que funcione.
Desenvolvimento Orientado a Comportamentos é uma metodologia criada com base no TDD, mas que evoluiu para um processo que não diz respeito apenas a programadores e testadores, mas que lida com toda a equipe e todos os interessados importantes, técnicos e não técnicos. O BDD começou com algumas perguntas simples que o TDD não responde bem: quantos testes devo escrever? O que devo realmente testar - e o que não devo? Quais dos testes que eu escrevo serão de fato importantes para os negócios ou para a qualidade geral do produto e quais são apenas os meus excessos de engenharia?
Como você pode ver, essas questões exigem colaboração entre tecnologia e negócios. As partes interessadas nos negócios e os especialistas em domínio geralmente podem dizer aos engenheiros que tipos de testes parecem úteis - mas apenas se os testes forem de alto nível que lidam com aspectos importantes dos negócios. O BDD chama esses testes de negócios de "exemplos", como em "me diga um exemplo de como esse recurso deve se comportar corretamente" e reserva a palavra "teste" para verificações técnicas de baixo nível, como validação de dados ou integração de APIs de teste. A parte importante é que, embora os testes possam ser criados apenas por programadores e testadores, os exemplos podem ser coletados e analisados por toda a equipe de entrega - por designers, analistas e assim por diante.
Em uma frase, uma das melhores definições de BDD que encontrei até agora é que o BDD é sobre "ter conversas com especialistas em domínio e usar exemplos para obter um entendimento compartilhado do comportamento desejado e descobrir incógnitas". A parte da descoberta é muito importante. À medida que a equipe de entrega coleta mais exemplos, eles começam a entender o domínio dos negócios cada vez mais e, assim, reduzem a incerteza sobre alguns aspectos do produto com os quais precisam lidar. À medida que a incerteza diminui, aumenta a criatividade e a autonomia da equipe de entrega. Por exemplo, agora eles podem começar a sugerir seus próprios exemplos que os usuários de negócios não consideravam possíveis por causa de sua falta de conhecimento técnico.
Agora, é ótimo ter conversas com especialistas em negócios e domínio, mas todos sabemos como isso acaba na prática. Comecei minha jornada com a tecnologia como programador. Como programadores, somos ensinados a escrever código - algoritmos, padrões de design, abstrações. Ou, se você é um designer, é ensinado a projetar- organize informações e crie interfaces bonitas. Porém, quando conseguimos nossos empregos de nível básico, nossos empregadores esperam que "agreguemos valor aos clientes". E entre esses clientes pode ser, por exemplo ... um banco. Mas eu não sabia quase nada sobre operações bancárias, exceto como diminuir eficientemente o saldo da minha conta. Então, eu teria que traduzir de alguma forma o que é esperado de mim em código ... eu teria que construir uma ponte entre o setor bancário e meus conhecimentos técnicos, se eu quisesse agregar algum valor. O BDD me ajuda a construir essa ponte sobre uma base estável de comunicação fluida entre a equipe de entrega e os especialistas em domínio.
Saber mais
Se você quiser ler mais sobre o BDD, escrevi um livro sobre o assunto. “Writing Great Specifications” explora a arte de analisar requisitos e o ajudará a aprender como criar um ótimo processo BDD e a usar exemplos como parte essencial desse processo. O livro fala sobre a linguagem onipresente, coletando exemplos e criando as chamadas especificações executáveis (testes automatizados) a partir dos exemplos - técnicas que ajudam as equipes do BDD a oferecer ótimos softwares dentro do prazo e do orçamento.
Se você estiver interessado em comprar "Writing Great Specifications", poderá economizar 39% com o código promocional 39nicieja2 :)