Hoje, pela hora de almoço, estava conversando com Gabriel sobre a questão do TDD (Test Drive Development – Desenvolvimento dirigido por teste). Conversávamos sobre o fato de hoje isso esta se tornando uma moda e muita gente dizer que está usando a técnica e na verdade não está.
Para os nerds de plantão, existe uma cena do filme Matrix, onde o Neo começa a entender a matrix e com isso controlá-la. Pode parecer que quero “forçar a barra”, porém acredito, sinceramente, que o uso TDD se processa da mesma coisa. Só vamos deslumbrar o seu poder quando passamos a acreditar no processo. Não adianta somente usar porque agora virou moda… tem que acreditar que a coisa realmente funciona, para então aproveitar todo o poder que essa verdade libera (estou inspirado hoje).
Tem muito gente que critica o uso do TDD por justamente se basear em casos onde pessoas que não acreditam no processo e usam por motivos não muito nobres. Nessas casos o que vejo são, na maioria das vezes, desenvolvedores subvertendo a filosofia, escrevendo testes que não são “profundos”, escrevendo os testes depois, adaptando os testes para passar ( já ouvi histórias de pessoas comentarem o teste), e por aí segue esse terror.
É preciso crer. O começo é verdadeiramente complicado e trabalhoso. Escrevemos toneladas de linhas de código, sem gerar nenhum valor “real” para nosso cliente. Por várias vezes ficamos tentados a deixar os teste de lado e partir direto para implementar por motivos diversos. Mas ao respeitarmos a formúla, o ganho vem com o tempo. Apenas para exemplificar, uma dessas vantagens é a questão de sempre estarmos focado no simples e atender estrictamente o escopo.
Quem nunca se deixou levar, ao implementar, uma aplicação, pela loucura de criar arquitecturas imensas e sem necessidade? Aquelas aplicações (Java) com um amontoado de camadas – DAOs, VOs, Services, etc – que no final vão servir apenas para um site pequeno de noticias que não terá grande modificações após ser colocar em produção.
Voltando para a questão do TDD… Escrever testes antes da implementação faz com que foquemos na necessidade: Criamos a necessidade para podermos supri-las e não contrário – criar soluções para depois ver necessidades.
Ser simples é chave. E TDD é um dos caminhos que nos levam a isso quando falamos em desenvolvimento de sistemas. Além disso, existe já as justificativas de ampla cobertura de testes e de foco na aderencia de requisitos.
Quando realmente usamos o TDD, como já disse antes, criamos a necessidade e a partir daí partimos para criar a solução que a satisfaçam. Isso faz com que tenhamos um código amplamente testado, justo – evitasse o desperdício em criar solução para necessidades que nem existem ainda, código limpo, etc. Se extrapolarmos então para a questão da evolução de código a coisa fica mais interessante ainda: primeiro modificamos o testes, pois a necessidade é diferente, e depois modificamos a implementação para passar nos novos cenários de teste. Isso limita nossa área de atuação e nos disciplina a fazer apenas o justo necessário. Sem firulas, sem big to front, sem complexidades adicionais para supostos futuros contextos.
Ainda sobre a vantagem, seria dizer que você, usando TDD e acreditando verdadeiramente, você está otimizando o uso do sprint e com isso gerando mais valor agregado para o cliente. Pensem nisso na próxima vez que tive seu projeto pela frente.
http://blogblogs.com.br/
Excelente post.
Realmente tem que acreditar. Eu e um amigo estamos começando a utilizar TDD, e, sem dúvidas, é simples, mas tem que ter foco e entender o processo.
Parabéns!
Bom post André. Você tem razão, é preciso acreditar e principalmente dar tempo para que os resultados apareçam. Acho que as pessoas ficaram viciadas no negócio de “apertar e ligar”. Acho que escrevendo um teste apenas a mágica vai acontecer.
Valeu!