O que é TDD e BDD?

O mundo da tecnologia tem muitas siglas e termos. Não conhecemos alguns por falta de familiaridade ou simplesmente não conseguimos decorar todos 😅.

Mas se você desenvolve software ou trabalha diretamente em projetos de desenvolvimento, já deve ter ouvido falar de Test Driven Development, o famoso TDD e também de Behaviour Driven Development (ou apenas BDD). Vamos abordar o que são essas técnicas, que problemas buscam resolver e vantagens de aplica-las no desenvolvimento de softwares.

Test Driven Development (TDD)

Desenvolvimento Guiado por Testes é uma técnica que se baseia em um ciclo curto de repetições que são três:

• Ciclo 1 (Vermelho): teste unitário é criado com base na necessidade da funcionalidade que ainda não existe em código, ao ser executado, deve falhar (pois não existe lógica criada);

• Ciclo 2 (Verde): o desenvolvedor cria um código que seja suficiente para passar com sucesso no teste que foi escrito recentemente;

• Ciclo 3 (Refactoring): melhorar o código a fim de seguir boas práticas, deixando-o mais limpo e legível para outros desenvolvedores.

TDD é realizar testes primeiro e depois implementar o código e a lógica da funcionalidade. Assim garantimos que os testes sempre fazem parte do desenvolvimento e nunca vamos deixar para depois ou esquecer de cria-los. Os teste são parte fundamental de qualquer grande projeto de Software. Podemos criar testes sem a técnica do TDD? Sim, com certeza. Mas a metodologia foi criada exatamente para isso, quando escrevemos os testes primeiro, pensamos com clareza de como o código deve ser e suas regras. Assim também evitamos bugs bobos em produção que atrasam o processo de entrega ou até mesmo quebram uma sprint.

O TDD surgiu nos anos 90. Kent Beck apresentou a técnica. O engenheiro de software também é um dos criadores do Extreme Programming (ou XP), que está em uso desde 1996. TDD é um dos pilares da XP.

Beck detalhou a técnica no livro “TDD – Desenvolvimento Orientado por Testes” onde apresenta exemplos práticos e bem legais de como codificar e executar testes do seu software.

Para que a técnica funcione é preciso realizar o teste em cada funcionalidade do código e sempre seguir os ciclos. Os testes tem como objetivo avaliar o comportamento de classes e métodos específicos e se eles estão realmente funcionando como foi previsto e escrito em código.

O TDD encoraja designs de código limpos, simples e de confiança. Colocar em prática pode ser desafiador no inicio, mas traz vantagens ao longo do tempo do projeto e prolongam a vida do software. Fica mais fácil desenvolver e até mesmo entender códigos que são desenvolvidos seguindo essa técnica. Vamos dar uma olhada nas vantagens.

Vantagens do Desenvolvimento Orientado por Testes

Podemos listar as principais:

• Código bem escrito e limpo;

• Colocando em prática o TDD ganhamos economia de tempo sem perder qualidade de desenvolvimento, com menos bugs para corrigir que irião para produção e menos retrabalho. Conseguimos evitar corrigir problemas que poderiam ser facilmente detectados pelos Testes;

• O desenvolvimento orientado a testes nos ajuda a documentar. Quando rodamos os testes, eles tem uma descrição do que fazem e assim fica mais fácil entender as funcionalidades de cada classe e métodos;

• TDD ajuda a eliminar códigos desnecessários. Quando se está desenvolvendo utilizando a técnica, o programador precisa se planejar bem e entender as regras e validações que a funcionalidade possui;

• Se praticar o TDD, o desenvolvedor divide seu trabalho em pequenas etapas. Quanto mais cedo receber feedback, menos tempo ele perde tentando achar problemas no código. Quando se tem muito código já escrito, mudanças podem ser trabalhosas e custar tempo valioso. Aplicando o TDD temos outro caminho, quanto menos código escrito, menor será o tempo e custo de mudança. É justamente isso que acontece com quem coloca em prática a técnica: recebem feedback e já partem para refactoring no código, esse processo é mais simples e rápido;

E o que é BDD?

Ela foi apresentada por Dan North nos anos 2003 como uma evolução do processo de metodologia do TDD. Dan North queria aproximar a áreas não técnicas no processo de criação das funcionalidades técnicas do sistema. E por que unir diferentes departamentos?

Quando desenvolvemos software, de forma involuntária podemos deixar de incluir regras presentes na funcionalidade, gerando possíveis bugs graves que podem ir para produção. E isso ocorre não por negligência da equipe de desenvolvimento, mas sim por falta de comunicação com quem é o domain expert do negócio.

Desenvolvimento Guiado por Comportamento (Behaviour Driven Development) serve exatamente para evitar erros bobos. BDD tem como principal ideia descrever o comportamento esperado da funcionalidade e não tentar dizer como ela deve ser implementada. É um processo colaborativo que envolve vários membros do time, trabalhando em sincronia. O objetivo é entender e refinar os requisitos usando, para isso, conversas sobre exemplos de casos de uso e comportamentos que a funcionalidade ou sistema devem ter. Com objetivo de buscar o entendimento compartilhado. E como funciona as etapas do BDD?

O processo do BDD se baseia na escrita de cenários de testes chamados de features que contém os requisitos e critérios do comportamento do sistema. Os cenários nos ajudam a entender o que a funcionalidade precisa ter para ser executada, o que ela fará e quais serão os resultados após a sua execução. As funcionalidades são descritas por três palavras básicas que definem o corpo da linguagem. Dado (Given), Quando (When) e Então (Then). Não é necessário seguir ao pé da letra as palavras citadas para criar os cenários, mas o criador North recomenda que seja estabelecido um padrão para a escrita, para que a comunicação entre as partes seja clara. Veja um exemplo de como ficaria esse arquivo de teste:

E quem escreve esses comportamentos que acabamos de ver?

Os cenários de testes não são escritos apenas por uma pessoa ou apenas pela equipe de desenvolvimento. Existe um conceito na metodologia ágil, difundida por Georgie Dinwiddie, chamada de regra dos três amigos. Três agentes principais que devem interagir diretamente entre si para construir um produto com melhor qualidade. Podemos citar que o Product Owner ou o Domain Expert, o QA e o programador responsável por criar a funcionalidade em código, se reúnem para escrever os cenários de testes da melhor forma possível.

Caso o papel de escrita dos cenários fique na responsabilidade de apenas uma das partes, não seria de grande ajuda aplicar a metodologia de BDD ao testar seu Software, pois ela perde seu principal propósito.

TDD e BDD andam de mãos dadas

BDD complementa o TDD. Dan North comenta que muitos times tinham dificuldade em aplicar as funcionalidades de TDD por não saber por qual teste começar ou o que escrever em seguida. TDD continua valendo. Escrevemos o teste antes, esperamos ele falhar, o desenvolver cria o básico da funcionalidade para ele passar e depois pode refatorar. A diferença é que o BDD funciona externamente, atuando na construção das funcionalidades e dos cenários de teste. Veja a imagem abaixo que ilustra bem isso:

Vantagens de se aplicar o BDD

• Compartilhamento do Conhecimento: Uma vez que todos trabalham em conjunto, é apenas uma questão de tempo até que os conhecimentos das duas áreas sejam transferidos e compartilhados. Pois como todos os envolvidos estão cientes de todos os cenários e estórias de cada funcionalidade, compartilhar esse conhecimento fica mais fácil.

• Estimula participação do Cliente: No BDD o próprio cliente pode definir comportamentos e escrever o que vai ser testado. Mesmo que não escreva é ele quem valida estes comportamentos da aplicação. Também é mais fácil explicar como determinada funcionalidade está sendo testada e seus comportamentos quando algo não sai como esperado.

• Ajuda a modelar o Domínio: A implementação de comportamentos e cenários por parte dos desenvolvedores faz com que eles tenham um melhor entendimento das regras de negócio e do domínio da aplicação. Sem contar o fato de ao melhorar o design possivelmente estamos diminuindo o acoplamento entre as classes.

• Nos ajuda a colocar em prática o TDD: Desenvolvedores que querem colocar em prática está técnica ao desenvolver podem se sentir mais interessados a partir do momento em que observarem as funcionalidades serem escritas com clareza.

• Construir a partir de funcionalidades individuais bem definidas ajuda a escrever códigos que são vagamente acoplado com arquitetura bem definida desde o primeiro dia. Melhora significativamente os testes, estabilidade e escalabilidade.

Conclusão

Podemos entender neste artigo as diferenças e também as vantagens de se trabalhar com as técnicas citadas. Em próximos artigos vamos abordar mais detalhadamente cada uma delas, principalmente o TDD. Fico por aqui neste post e agradeço muito por ler. Até!