TDD (Test Driven Development)
Olá pessoal! Hoje vou falar um pouco sobre TDD.
Teoria
TDD (Test Driven Development) é a técnica que consiste em codificar os testes antes de qualquer codificação de melhoria ou nova funcionalidade.
Testes unitários são códigos que executam (testam) uma única unidade de código, verificando se o mesmo foi escrito corretamente. São rápidos de serem executados provendo um resultado quase que imediato e de forma automatizada.
Vantagens
TDD auxilia no design de nossa classe, pois quando iniciamos pelo teste estamos iniciando por quem irá utiliza-la, desta forma podemos definir melhor como será a implementação de acordo com a forma que estamos utilizando a nossa classe.
Testes unitários podem auxiliar na codificação, pois eles devem ser simples de escrever e com poucas linhas. Se está complicado de fazê-lo, existe algo de errado com o código a ser testado ou com a lógica emprega, neste caso, refatore.
Podemos fazer uma refatoração de qualquer proporção no código que os testes vão avisar caso alguma coisa não está mais cumprindo o que foi definido.
A partir dos testes podemos ver exatamente como a nossa classe foi construída, conseguindo saber como cada regra foi garantida e como utilizar a classe testada.
Os testes acabam sendo uma documentação executável do código.
Organização
O teste seguirá basicamente o padrão AAA (Arrange, Act, Asset):
Arrange: É a configuração do ambiente antes de executar o teste.
Act: É a execução do método a ser testado.
Assert: É o que garante que determinada funcionalidade foi desenvolvida.
Etapas
O TDD é composto por três etapas muito simples que são basicamente: Vermelho, Verde e Refatorar.
Vermelho: É a etapa na qual o teste não está passando; simplesmente é quando iremos definir como o nosso método será executado e quando definimos a nossa assertiva.
Obs.: Em TDD temos sempre que começar pelo teste mais fácil.
Verde: É a etapa na qual o teste passa; temos que fazer o teste passar da forma mais simples e rápida.
Obs.: Em TDD é necessário sempre simular antes de construir a implementação real da classe. Esta técnica ajuda a entender melhor o problema e nos dá mais tempo para elaborar a implementação do código e, em TDD, você deve fazer apenas o necessário para o teste passar.
Refatorar: É a etapa na qual iremos melhorar a implementação do código da classe.
Obs.: Todos os testes que estavam passando na etapa anterior devem continuar passando após a etapa de refatoração, por isto é muito importante sempre executar todos os testes e não apenas o que você está codificando.
Dicas
Lista de teste: Antes de implementar nossos testes, será sempre melhor, elaborar uma lista de teste, assim podemos guiar o desenvolvimento da nossa classe de teste a partir desta lista. Além de ser um plano de desenvolvimento da classe, a lista de teste também nos ajuda a escolher qual será o teste mais fácil de ser implementado.
Passos de bebê: Note que em TDD sempre desenvolvendo o nosso código pouco a pouco, seguindo as três etapas acima. Esta técnica é chamada de passos de bebê, desta forma, garantimos, que cada item da nossa lista de teste está correto até chegar à implementação final da nossa classe, o resultado será um código bem feito e simples, apenas para atender a real necessidade do problema.
Triangulação: Mesmo tendo certeza que o teste irá passar, é sempre recomendada a triangulação, ou seja, fazer testes com corpos parecidos, porém, com dados diferentes, para ter certeza que a regra esta sendo cumprida corretamente.
Nomes objetivos: Nossas classes de teste bem como os nossos testes devem conter um nome que representa claramente o que será feito, pois o nosso projeto de teste também pode ser usando como uma documentação executável, assim, qualquer pessoa que ver este teste saberá exatamente o que está sendo testado.
Uma assertiva por teste: Cada teste terá apenas um método de assertividade, assim, quando um teste falhar será possível saber exatamente qual foi o problema e o que há de errado com o método.
Criando um cenário antes de codificar: Caso haja uma situação na qual o teste não passe, deve-se criar um teste para esta situação. Isto vale também para uma situação em produção, imagina que acorra um bug no sistema, você criará um teste para simular o erro antes de implementar a solução.
Obrigado pela visita e espero que tenha gostado, até a próxima.