Falhas primeiro, Features depois
Tags: tdd
Published: 2022-03-10 11:29:25

Comecei a estudar TDD recentemente e aplicando isso em um projeto pessoal e no trabalho, acabei percebendo um padrão que estava começando a surgir no meio dos meus estudos.  
  
Sempre que eu pensava em um teste para escrever, eu já fazia questão de pular a fase do *Red* e ir direto para o *Green*, pulando assim toda a importância da primeira fase do RGR. Conversando com alguns desenvolvedores percebi que isso é um padrão que se repete entre quem esta começando os estudos em Desenvolvimento Orientado a Testes. Aqui, vou tentar explicar do meu ponto de vista o porquê acho que é de extrema importância não violarmos o ciclo RGR.  
  
Antes de tudo, vamos revisar o que essas letras significam dentro do TDD:  
  
- ***Red***: Aqui é onde o TDD começa. Como estamos desenvolvendo orientado a testes, a ideia é começar o desenvolvimento escrevendo testes que devem falhar. E assim rodamos os testes para checar a falha.  
- ***Green***: Após escrever testes que falhem propositalmente, escrevemos o mínimo de código de produção para que os testes passem. Rodamos os testes novamente para verificar isso.  
- ***Refactor***: Nesta ultima fase, enxugamos o código de produção que foi escrito para que os testes passassem. Nessa parte, removemos duplicatas de código, partes do código que estão hardcoded e implementamos algumas otimizações. Se algum teste for quebrado neste processo, priorizamos voltar a fazer o teste passar novamente antes de concluir esta fase.

Pois bem, após alguns dias aplicando o TDD eu comecei a me achar um pouco lento no meu processo de escrita de código e comecei a pular a parte do Red e a apenas escrever testes que passassem, sem forçar a falha. Mas por que temos esse comportamento de sempre temer a falha?  
  
O problema, principalmente de nós Juniors que estamos começando, é que estamos presos nesse método abaixo:


![Metodo anti-pattern seguido por quem está começando](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/anfhxtxl6pmy7umed82m.png)

A falha desse padrão acima é que estamos perdendo todas as vantagens que o TDD tem a nos oferecer, como por exemplo, qualidade de código, melhora na manutenção de código e redução de tempo e custo para manter e construir produtos de grande escala. Mas quais os motivos de seguirmos esse tipo de padrão quase que naturalmente? Vou listar 2 motivos que eu acredito ser a causa disso:

- Tendência natural a evitar falhas.

Vivemos sempre tendendo a olhar para o sucesso, e tememos a falha. Quando estamos desenvolvendo no TDD, vamos diretamente contra isso e buscamos a falha logo de inicio. Por isso acaba sendo muito estranho para a maioria dos desenvolvedores.

- Ansiedade para implementar novas features

Outra coisa que acontece muito é ir com sede de implementar uma feature nova no projeto. Esse talvez seja o principal motivo que nos leva a seguir o anti-pattern, pois implementar uma feature logo de inicio nos da uma sensação de trabalho feito.

*Mas então, como devemos seguir o TDD?*

Seguindo o RGR, sempre, repito, **sempre** iremos começar a escrever os testes de forma que eles falhem propositalmente. E por que isso? Imagine que você escreveu um teste de forma com que ele já passe automaticamente, o que você sabe sobre ele? Absolutamente nada.

*Sempre duvide do silêncio dos seus testes.*

Podemos ter escrito um teste que na verdade não está testando nada, mas que quando executado ainda sim indica que o teste passou. Por isso é de extrema importância que você rode seus testes de forma a fazer com que eles falhem, para então reescreve-los de forma a fazer eles passarem. Não importa o que aconteça, temos de sempre seguir o RGR.

O fluxo de um TDD bem feito seria da seguinte forma:


![Fluxo simples de TDD](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ixlf9hksc8sm2ax2jljf.png)

Por mais que o início seja complicado e muitas vezes você sinta que o seu processo de escrita de código esteja lento, tenha paciência e confie no TDD. No final das contas, você esta melhorando a qualidade do seu código e das suas entregas.