TDD: Desenvolvimento Orientado a Testes

Todo código é culpado, até provarem o contrário Esse post foi originalmente escrito para o Profissionais TI, você pode conferi-lo na íntegra aqui.

O caos!

Hoje em dia o agile passou de uma “técnica anarquista” para uma saborosa realidade, principalmente nas startups de tecnologia.

Uma das características de qualquer método ou ferramenta agile é que: Qualidade não é negociável; Como podemos garantir que ao final de cada ciclo de entregas estamos entregando uma solução que atenda escopo, prazo e também qualidade?

Test first

Metodologias ágeis como o Scrum e o XP adotam a técnica “Test First”:

  • Primeiro escreva um teste que falhe
  • Depois escreva um código que faça o teste passar
  • Melhore o código escrito

Red, Green, Refactor! Além da garantia de que sua aplicação irá funcionar após uma atualização ou bugfix, devemos levar em conta que estamos indo além do simples ato de testar. É nisso que muita gente se confunde quando fala-se em Test-Driven Development: Não trata-se apenas de testes, trata-se de design!

Os testes passam a ser a sua especificação, passam a ser a forma de você medir se o seu software está sendo conduzido para o real objetivo ou não. Literalmente, os testes guiam o seu desenvolvimento – mas isso não garante que a solução como um todo esteja funcional, por isso é necessário uma pitada de bom senso (como em tudo na vida).

Quando você menos espera, a construção dos testes automatizados passou de “testes” para “desenvolvimento”. Ou seja, esse método irá fazer parte do processo de construção de código e você começará a medir qualquer estimativa referente a codificação com os testes inclusos, naturalmente.

A Web está repleta de artigos sobre como construir estes testes, como executá-los, etc. Então, não vou ficar repetindo o que já foi “dito” e vou deixar referências de pessoas mais “conhecidas” do assunto:

Automatizar = Agilidade?

Mas porque TDD ajuda tanto? Será que vale a pena praticar?

Quando comecei a programar orientado a objetos, tinha em mente que aquilo era só curiosidade, que no modo estruturado estava muito bom e não via a real utilidade daquilo tudo. Claro, isso até ser completamente envolvido por OOP, e quando me dei conta não sabia mais viver sem ele.

Agora já posso dizer o mesmo de TDD. O prazer de construirmos orientados a testes, através de um processo baby-steps, é desafiador… voltei a acreditar que posso fazer software bom e de qualidade, pois:

  • A taxa de acerto é alta
  • A ocorrência de erros diminui
  • Você ganha confiança no que está produzindo

Mesmo que você perca tempo não previsto no desenvolvimento, poupa tempo (espero eu que) previsto nos testes. No começo a performance do desenvolvedor cai significativamente… mas com o tempo irá tornar-se uma prática para dar maior segurança em relação a qualidade do seu software, e também dar maior segurança a você.