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.