Como eu conheci o TDD?

Durante minha passagem para trabalhar como desenvolvedor no nTopus uma das minhas maiores preocupações era o fato de eu não efetuar testes. Porém a minha visão antes de conhecer melhor era meramente que testes evitavam problemas desnecessários de serem resolvidos (Na minha máquina funcionou perfeitamente, é óbvio que tudo foi testado manualmente 🤦‍♂️). Sendo assim fui apresentado ao desenvolvimento orientado a testes (TDD (Test Drive Development)) e o fluxo de produção é basicamente: Planejar teste, Projetar o teste, executar o teste, Codificar, Refatorar o código.

O que ganhamos utilizando esta abordagem?

Este tipo de abordagem por mais que pareça ser contraituitivo, faz sentido pois entende que o código precisa se adequar as regras de bom funcionamento, e não o contrário; e que o refatoramento do teste para torná-lo mais assertivo, naturalmente forçará ao código melhorar para novamente se adequar a esta nova realidade mais rigorosa, “Parece meio infinito não?“.

Ao testar o TDD foi engraçado ver que a medida que eu criava os testes as assinaturas (nome do método, parâmetros e tipos de retorno) dos meus métodos necessários para o funcionamento das minhas classes estavam aparecendo quase que por conta própria e mais curioso foi, quando ao refatorar meu teste isso gerava uma nova visão sobre o código e o que ele deveria melhorar.

Exemplificando

Digamos que queremos criar um padrão de senha, e que na nossa senha vamos ter uma regra de criação simples, como a senha necessita ter exatos 6 digitos e apenas números. Apenas com isso teremos que:

Criar uma senha precisa ter perfeitos 6 digitos. Logo se a senha tiver menos/mais dígitos ela é inválida e que se não for completamente composta por números também é inválida.

Para orientar a criação de nossos testes, precisamos entender o que são Caminhos felizes e tristes. Caminhos felizes são toda a rota de verificação onde tudo dá certo e acontece conforme o esperado, resumindo é o melhor dos mundos. Caminhos tristes são as possibilidades de erro, ou as formas incorretas de utilizar a aplicação. Portanto trata-se do inferno batendo na porta de seu código.

Somente com isso já temos:

Caminhos Felizes:

• Criar uma senha válida.

Caminhos Tristes:

• Criar uma senha com digítos a mais.
• Criar uma senha com digítos a menos.
• Criar uma senha com números e letras.

Primeiro criaremos nossos testes (Que não irão passar). Observe que mesmo sem ter feito a implementação. nós já temos alguma ideia de como vamos criar a nossa verificação.

E falhou 😕 (Claro… se não implementamos nada ainda.)

Coisas que descobrimos somente criando o teste:

• Nome do método: verifyPasswordRule
• Assinatura do método: verifyPasswordRule(password: number) : boolean

Então vamos implementar!

e Passou!

Mas vamos ao refatoramento do nosso teste.

Perceba que quando erramos a nossa senha, não há forma de entender o que erramos ou pelo menos como acertar e quando passamos a ter uma cabeça de que este é o tipo de coisa que apareceria em um front-end as mensagens de erro ou acerto de formulários devem ser retornadas, evitando uma despadronização nas mensagens de formulários. Então vamos aplicar deste comportamento ao nosso teste.

Agora criaremos a interface de retorno do nosso método:

E agora vamos refatorar a nossa implementação!

E passou novamente!

E agora para assegurar que os futuros refatoramentos (ou implementaçoes!) que irão ocorrer irão manter o mesmo grau de performance, sendo assim iremos adicionar um timeout aos testes

E passou!

Com este exemplo foi possível verificar um fluxo básico de desenvolvimento orientado a testes, e além disso compreender os benefícios dessa abordagem. Por mais que seja mais trabalhoso a princípio, o ganho em segurança e confiabilidade é realmente imenso!
Para mim foi uma mudança de paradigma muito grande e atualmente antes de desenvolver algo eu já costumo pensar em como esse teste seria feito e o que eu gostaria de testar para assegurar que meu desenvolvimento foi feito com sucesso, e isso é algo bom para mim e também para os sistemas ao qual eu futuramente irei me envolver. Espero que este artigo seja útil para você de alguma forma e caso tenha algo a adicionar pode comentar! estou aberto ao ganho de conhecimento e críticas construtivas.