As pessoas realmente fazem TDD?
Tags: testing, tdd, braziliandevs
Published: 2020-11-03 19:00:48

Muitos sabem o que é TDD e que ele pode [mudar a sua vida](https://medium.com/javascript-scene/tdd-changed-my-life-5af0ce099f80), mas muitas pessoas se fazem a pergunta:

> Será que as pessoas realmente fazem TDD? Ou é só coisa de artigo?

É bem estranho pensar que seu chefe vai deixar você trabalhar em testes e não em código. Existe a mentalidade que melhorar as coisas para os desenvolvedores não traz valor ao cliente.

Vamos aos básicos primeiro.

## TDD, o que é?

TDD é um técnica de programação onde você codifica o teste antes da funcionalidade. Isso envolve que o teste sempre começa falhando, você codifica apenas o necessário para o teste passar (isso de qualquer jeito, não precisa ser da melhor forma), depois refatora o código e o teste tem que funcionar novamente.

Esse comportamento é representado com os estados:

*vermelho* -> teste falha
*verde* -> teste passa com o mínimo de código possível
*azul* -> código é refatorado
*verde* -> teste passa

## Qual o poder mágico que o TDD tem?

### TESTES

TDD não é magico. A magia está nos testes!

O TDD te força a fazer testes pro seu código inteiro. Se você modificar seu código sem testes, como você sabe que ainda está tudo bem? 

Como você sabe que não quebrou o código que seu colega fez? Quem ja trabalhou com código legado entende muito bem essa dor, essa incerteza de fazer uma modificação e estragar alguma coisa.

Isso é uma ótima vantagem para times com uma pessoa com menos experiencia, onde ela sabe que fez algo de errado por que o teste quebrou, o que deve evitar o código ir pra produção.

Testar manualmente é uma opção, mas vai ocupar cada vez mais tempo. Os testes automatizados são a melhor forma de garantir que você não estragou nada.


## Muitas pessoas fazem testes, nem tantas fazem TDD


Muitas pessoas vão falar com seus chefes e lideres de time sobre fazer TDD, isso é muito legal, mas a maior parte das vezes vai ser levado como utopia e não será implementado. 

O argumento mais comum é:
> TDD é muito custoso, deixa o time mais lento, esse código nem é uma funcionalidade. No final vai ser tempo perdido.

Existem algumas coisas certas nesses argumentos:
- Seu time pode ficar mais lento.
- Esse código não tem contato direto com o cliente.

**Mas não é tempo perdido.**   

É criar uma melhor experiencia de desenvolvimento, trazer mais qualidade para o produto e ajudar os desenvolvedores do time a serem melhores.

## Experiência no desenvolvimento traz valor!

Quem nunca pegou um projeto, pra resolver uma coisa bem pequena e simples e demorou o triplo do esperado para concluir a tarefa? Ou então construiu uma funcionalidade e a colocou em produção para perceber que tinha uma regra de negócio errada?

Trabalhar com código é difícil, ainda mais se ele é de outra pessoa e ainda por cima está incompreensível. Se o código estivesse melhor, você ia demorar tanto pra fazer modificações nele?

A sua experiencia no desenvolvimento, como programador, é importante. Sempre pensam que os testes "atrasam" o desenvolvimento, mas nunca olham para quanto um código ruim pode fazer uma tarefa de dois dias demorar um mês.

> Com modificações sendo feitas de forma mais rápida, mais valor é entregue em menos tempo!

## Qualidade

Garantir a qualidade não é um trabalho exclusivo do QA. A qualidade tem que estar em todos os processos do desenvolvimento, desde a analise da tarefa e suas regras de negócio, o desenvolvimento e o processo de validação do que foi desenvolvido.

Fazer testes unitários automatizados é a ferramenta usada pelos desenvolvedores para garantir a qualidade durante o desenvolvimento, no presente e no futuro.

Esses testes estão na base da pirâmide, sendo eles os menos custosos de executar e criar. Se você está tendo problemas de qualidade dentro do seu time/projeto, TDD é um dos melhores passos a se dar. 

**Dica bonus**
Uma coisa que pode ajudar muito também é uma conversa mais próxima de desenvolvedores e analistas de negocio.

## Finalizando aqui

Você vai encontrar dificuldades de implementar o TDD, seja por falta de costume ou por que o time não esta aberto pra isso. Comece aos poucos, tente um pouco de TDD de cada vez, assim você fica mais rápido e vai entender melhor suas vantagens. 

Esse é um tema que a leitura não te trará conhecimento suficiente e que a pratica é a parte mais importante.