O que é TDD?

TDD significa “Test Driven Development”, que em potuguês pode ser traduzido para “Desenvolvimento Orientado a Testes”. É uma técnica de testes em que escrevemos um teste automatizado antes de qualquer linha de código de produção.

Quais são as vantagens de criar testes de unidade?

  • Pode melhorar a qualidade do código
  • Melhora a confiança para refatorar código
  • Ajuda a criar códigos sem bugs
  • Ajuda a criar códigos mais simples
  • Aumenta a manutenabilidade
  • Pode servir de documentação viva

Quais são as vantagens de criar testes automatizados?

  • Ajuda a economizar tempo
  • Evita trabalho repetitivo

TDD != Testes de Unidade != Teste Automatizado

Criar testes automatizados de unidade não significa que você faz TDD. Para praticarmos TDD, temos que seguir algumas regras:

  • Escreva o código de testes antes do código de produção (vermelho);
  • Faça o teste que agora está falhando passar (verde);
  • Refatore apenas quando todos os testes que foram criados estejam passando (azul).

Por que não escrever testes depois?

Um dos motivos para criar testes antes é de que você pode acabar criando código que não é testável e nem saber disso, e aí é tarde demais. Usando TDD não temos esse risco pois vamos testando o sistema a medida que ele cresce e também é mais divertido e menos arriscado ir fazendo aos poucos do que ter que escrever vários testes para uma funcionalidade que já foi escrita.

Não estou dizendo que não podemos escrever testes depois, antes tarde do que nunca. Se você ainda consegue criar testes para uma aplicação, faça-o. Porém se está começando algo do zero, não há desculpas. Escreva testes antes que sua aplicação vire uma bagunça não testável.

Mas escrever testes não podem tornar o desenvolvimento mais lento?

Inicialmente pode parecer que é improdutivo criar testes para cada linha de código que criamos, porém isso é pago a longo prazo pois não precisaremos testar manualmente nosso software toda vez que fizermos uma pequena alteração, fazendo com que o desenvolvimento fique mais ágil.

Devo criar testes para tudo?

Eu não vou mentir. Eu não crio testes para TUDO e eu acho que aí realmente seria improdutivo. Saber o que devemos testar é um desafio. O ideal é testar classes que têm alguma lógica. Parece óbvio, não? Mas não é. Eu não acho que vale a pena testar getters e setters que não façam nada além de atribuir, mas se ele faz alguma validação antes da atribuição, é interessante criar um teste.

Como começar?

Para que você entre no mindset de TDD, imagine que testaremos uma classe que remove acentos de frases. Antes de escrever qualquer código a não ser de teste, já somos obrigados a pensar em como será a interface dessa classe que ainda não existe. Qual será seu nome? Como vai se chamar o método? Quais parâmetros ele vai receber? Vamos assumir que a classe se chamará “RemovedorDeAcentos” e terá um único método público “remover”. Qual é o resultado esperado? No teste de unidade escrevemos um código que traduz basicamente a:

RemovedorDeAcentos.remover(‘São Paulo’) deve resultar em: “Sao Paulo”.

Dicas

  • Dê nomes descritivos para os casos de teste que criar;
  • Escreva o mínimo de código para o teste passar;
  • Dê passos pequenos;
  • Resolva um problema de cada vez;
  • Foque em fazer o teste que está quebrado passar;
  • Evite testar componentes terceiros que já possam ter sido testados;
  • Não teste a própria linguagem;
  • Teste a funcionalidade isolada que você estará entregando.

Próximos

No próximo post mostrarei como instalar um framework de teste de unidade num projeto em PHP e criaremos nosso primeiro teste.

Dúvidas e sugestões

E aí, gostou? Caso tenha alguma dúvida ou sugestão, deixe um comentário abaixo.