Hoje nós falaremos sobre TDD e BDD!
Logo que eu ouvi sobre eles gerou um confusão enorme na minha cabeça. O que é TDD e BDD ?
TDD – Test-Driven Development (Desenvolvimento Orientado a Testes) é o Desenvolvimento de Software orientado a Testes.
O processo de desenvolvimento do TDD seria:
- Escrever um teste, sem mesmo ter escrito o código real a ser testado (Imagine o que deseja testar).
- Executar os testes e acompanhar a falha (Pode ser um código falso que retorne o erro)
- Escrevemos a funcionalidade do sistema que iremos testar.
- Testar novamente, agora para passar (Se não passou algo saiu errado, faça novamente o passo 3)
- Refatore sua funcionalidade e a escreva por completo (o teste também) (Refactor)
- Passe para o próxima estória ou caso de uso e inicie novo teste.
Confesso que isso é bem estranho, principalmente os passos 1 e 2 rs, até porque se funcionasse sem código seria mais estranho ainda kkk.
BDD – Behavior Driven Development (Desenvolvimento Guiado por Comportamento ou Desenvolvimento Orientado a Comportamento)
BDD serve para criar testes e integrar regras de negócios com a linguagem de programação, focando no comportamento do software. Além disso, ainda melhora a comunicação entre as equipes de desenvolvimento e testes, aumentando o compartilhamento de conhecimento entre elas
O foco do BDD é tentar fazer com que todo mundo fale a mesma língua, sem se preocupar com termos técnicos e olha que legal, pode até ser mostrado ao cliente, já que é escrito usando linguagem natural. Pode ser considerado parte da documentação.
Antes de entender em qual parte cada um deles atuava, eu achava que a parte de implementação das funções era o TDD e os cenários o BDD, além de confundir o nome dos dois. Mas, o TDD é a técnica que eu vou utilizar junto ou não do BDD.
Para ilustrar um pouco melhor, temos um exemplo de vendas no GitHub, utilizando python e behave.
Ao realizar esse exemplo utilizando as técnicas pude observar e entender melhor o comportamento.
Como antes de escrever o código nós fazemos os testes, a medida que vamos testando vamos vendo as necessidades surgirem. No exemplo da venda, ao descrever esse cenário e testar, o processo em si já dava dicas do que seria necessário.
Por exemplo, para calcular o valor total da venda eu vou precisar de um método para pegar o preço do produto e de um para saber a quantidade. Isso parece óbvio, mas na hora de programar e montar sua lógica, utilizando essas técnicas as coisas se tornam mais fáceis e como o teste é automático, a chance de erro é bem menor do que se fossemos testar tudo na mão. Testar na mão, inconscientemente, você acaba colocando os valores que você sabe que darão certo rs, e no teste, não.
Os cenários descritos no BDD são casos de uso, e ao implementar os métodos, me lembrei da aula de projeto de sistemas, quando estávamos aprendendo sobre diagrama de sequência. Naquele dia, ele mostrou um caso de uso e colocou os métodos necessários ao invés só da escrita, como por exemplo:
Isso me fez pensar em como as coisas estão integradas, que o BDD, juntamente com o TDD, nada mais são que validações, com relação ao cliente, se é o que ele quer e verificações, se está sendo construído certo. E olha que massa, de forma automática!
Até mais!
Referências:
Comentários
Postar um comentário