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
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 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
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.
Top comments (0)