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