Conceitos básicos de TDD Com Typescript e mocha
Published: 2020-12-07 00:06:53

# 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 :man_facepalming:). 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.
![index](https://dev-to-uploads.s3.amazonaws.com/i/r3rpjfdosxbd85g7ivan.gif)
# 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.
![index](https://dev-to-uploads.s3.amazonaws.com/i/20fpp7e6qyuhqe19wfl5.png)
E falhou :confused: (Claro… se não implementamos nada ainda.)
![3](https://dev-to-uploads.s3.amazonaws.com/i/ske6i2wxui3dhnjnduft.png)
Coisas que descobrimos somente criando o teste:
* Nome do método: verifyPasswordRule
* Assinatura do método:
verifyPasswordRule(password: number) : boolean

Então vamos implementar!
![2](https://dev-to-uploads.s3.amazonaws.com/i/9rnnood8oqud699hf9j4.png)

e Passou!
![4](https://dev-to-uploads.s3.amazonaws.com/i/mguy86aakaa1g1s8xqnv.png)

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.
![5](https://dev-to-uploads.s3.amazonaws.com/i/zgmf2uflrmcvw4wurz1i.png)

Agora criaremos a interface de retorno do nosso método:
![6](https://dev-to-uploads.s3.amazonaws.com/i/3fh6omtnn9fkkvz23s4d.png)

E agora vamos refatorar a nossa implementação!
![7](https://dev-to-uploads.s3.amazonaws.com/i/hsb9hfa4xo1t3fzo27nq.png)

E passou novamente!
![8](https://dev-to-uploads.s3.amazonaws.com/i/dymfncwvq171lxk4djqa.png)

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
![9](https://dev-to-uploads.s3.amazonaws.com/i/zs9dg2r02xo9qrg4g7yv.png)
 
E passou!
![10](https://dev-to-uploads.s3.amazonaws.com/i/886ejflxcmqz12ziwx6l.png)

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.
![11](https://dev-to-uploads.s3.amazonaws.com/i/5991methcmv4ojwolws2.gif)