Recentemente, o criador do Ruby on Rails declarou que o TDD (Test Driven Development) está morto. Apesar de ter sido um grande apoiador do TDD como melhor método de desenvolvimento, ele finalmente decidiu anunciar que não concorda com isso.

Leia este artigo e entenda melhor o que aconteceu e o que isso quer dizer para desenvolvedores que utilizem ou não o TDD.

O que é TDD?

A comunidade de desenvolvimento de software é grande. Alguns desenvolvedores são bem mais experientes que outros. Portanto, eu acredito que deveria começar falando um pouco sobre o básico, para ajudar àqueles que não têm muita certeza do que seja TDD.

TDD é a sigla para Test Driven Development – Desenvolvimento Dirigido por Testes. É um processo de desenvolvimento de software que consiste em criar um código que teste se o código se o código real do projeto funciona como deveria.

Isso significa que primeiro você cria scripts de testes e depois o código em si do seu projeto. Então, você roda os testes para ver se algum deles apresenta erro. Nesse caso, você deve corrigir o código até que tudo esteja ok.

Kent Beck é o criador do TDD, ou ao menos quem redescobriu o processo em 2003 como forma de promover qualidade de software.

O debate

Na teoria, TDD é maravilhoso. Todo desenvolvedor quer escrever um software da melhor qualidade possível. Testes são uma forma de verificar que o software satisfaz os requerimentos do projeto. E isso não deveria ser algo ruim.

TDD é mais do que apenas escrever testes. É sobre escrever testes em primeiro lugar, antes mesmo de escrever qualquer componente do seu projeto. Isso leva a uma série de inconveniências que desencorajam muitos desenvolvedores a abraçar o TDD.

David Heinemeier Hansson, criador do framework Ruby On Rails, publicou um artigo admitindo que ele não usa TDD, apesar de no passado ter sido um dos defensores da metodologia como melhor forma de desenvolver software.

Após a publicação do texto, ele participou de um debate público com Kent Beck e Martin Fowler, promotores do Desenvolvimento Ágil/Agile. Esse debate aconteceu em diversos hangouts, que terminaram recentemente. Aqui está a playlist dos vídeos:

Então, por que o TDD falhou?

A argumentação contra o TDD é ampla. Diferentes oponentes ressaltam pontos distintos. Aqui, apresento apenas a minha opinião, com base no que eu acho ser mais relevante.

Algumas pessoas podem ter pontos de vista complementares, outras podem não concordar com os meus pontos. A ideia não é formar um consenso, mas oferecer a você uma perspectiva para refletir.

1. TDD é caro

Minha maior objeção ao TDD é que ele é caro. Se você precisa escrever testes para tudo antes de começar, obviamente o seu projeto vai levar mais tempo ou usar mais desenvolvedores.

Todo projeto de software pode falhar, especialmente se envolver dinheiro demais. Então, gastar ao escrever testes com antecedência pode fazer com que o seu projeto seja abortado antes de oferecer qualquer valor àqueles que estão pagando.

2. TDD vai atrasar o lançamento do seu projeto

Obviamente, escrever testes antes de começar vai fazer com que seu projeto demore mais para ser lançado. Alguns defensores dizem que o tempo gasto em fazer os testes será pago no futuro, se algum problema acontecer.

O fato é que você apenas vai quebrar algo se fizer uma mudança, ou mudar as dependências de forma significativa. Então, se você tem medo de quebrar algo e causar um problema no projeto devido a uma mudança, faça testes imediatamente após isso. Você não precisa escrever os testes do início.

Por outro lado, se você evita escrever testes do início, você ganha tempo, seu projeto será lançado mais cedo e o negócio pode ser validado mais rapidamente.

3. Você vai mudar os seus projetos, e os testes antigos serão ultrapassados

É bem frequente que projetos tenham seus objetivos alterados porque as empresas por trás deles percebem que algumas mudanças são necessárias, de forma que o negócio seja mais viável.

Quando os objetivos de um projeto mudam, ao menos uma parte do código se torna inútil, já que não será mais usado. Se você escreveu testes extensivos para o código que será deixado de lado, os testes também se tornarão inúteis. Acho que você já percebeu que o desperdício de tempo foi muito maior do que se você tivesse escrito apenas o código que fez o que deveria ter feito sem os testes.

4. Testar os meios dá mais trabalho que testar os resultados

Também é frequente a necessidade de mudar partes da implementação, sem alterar o resultado da sua aplicação. Por resultado, eu quero dizer por exemplo aquilo que precisa acontecer ou o que você tem que mostrar para o usuário.

O resultado é o principal a ser preservado. Se o software deixa de funcionar ou funciona de forma errada, os meios que foram usados para gerar o resultado também não estão funcionando corretamente. Para chegar a essa conclusão, você não tem que ter testado absolutamente todos os pequenos componentes de software que implementaram os meios.

No entanto, os componentes que implementaram os meios geralmente representam uma parte maior do seu projeto de software, então requerem muito mais testes, e você precisa gastar mais tempo nisso.

5. Testes extensivos são chatos

Testes não são funcionalidades. São apenas verficações. Para muitos desenvolvedores, gastar muito tempo escrevendo testes faz com que se sintam muito menos produtivos, porque eles precisam gastar muito mais tempo para ver o resultado final.

É por isso que muitos profissionais não gostam de escrever testes. Eles preferem que alguém faça isso para eles. Fazer com que um desenvolvedor escreva testes contra sua vontade é como uma tortura. E programar se torna uma obrigação dolorosa, ao invés de um prazer.

Com o tempo, muitos desenvolvedores passam a odiar ter que escrever testes, até mesmo os que são para verificar coisas cruciais que não podem falhar, como o resultado da aplicação.

Essa é provavelmente a razão pela qual muitos dos que eram entusiastas de TDD desistiram disso para sempre.

6. Muitos evangelistas de TDD não usam a metodologia na maior parte do tempo, mas não admitem isso

Muitos se tornaram tão entusiastas do TDD que pregavam isso como se fosse uma religião. Se alguém não praticava a metodologia, ganhava um sermão. Para esses evangelistas, não usar TDD era um pecado e você iria para o inferno quando morresse se não se convertesse à religião TDD.

Isso não seria tanto um problema se os praticantes do TDD não tivessem se arrependido e largado de mão. O problema é que, ao desistir, temeram admitir isso em público e apanhar dos pregadores, e seriam culpados de inconsistência nas suas crenças passadas.

Foi mais ou menos isso que aconteceu com David Heinemeier Hansson. Ao perceber que o TDD não era muito bom, ele evitou comentar sobre isso para não ser eventualmente julgado. Após 10 anos, ele finalmente resolver revelar tudo. Ele não usa TDD de forma alguma.

Ele também se sente mal por todos os outros profissionais que temem admitir que não usam o TDD apesar de terem sido entusiastas no passado. Alguns ainda usam a prática em parte dos seus projetos, especialmente em projetos Open Source, quando todos podem ver o que os outros fizeram. Mas, para projetos privados, eles raramente usam.

7. Muitos desenvolvedores com boa reputação não usam TDD       

Você não precisa ser super inteligente para perceber que TDD não é algo para ser usado em todos os seus projetos. É até mesmo estarrecedor que o David Heinemeier Hansson tenha levado 10 anos para declarar que TDD não é a melhor escolha para ele.

É ainda mais impressionante porque profissionais de renome e boa reputação já falaram contra o TDD no passado. É o caso dos fundadores do StackExchange, Joel Spolski e Jeff Atwood. Em 2009, eles declararam em um podcast do StackOverflow que não usavam TDD.

E eles não são os únicos a pensar assim. A questão é que eles não têm medo de falar o que pensam. Mas quando falaram, “Uncle Bob” (Robert Martin) discutiu com eles em um episódio seguinte do podcast. Então, outros desenvolvedores ficaram com medo de admitir isso publicamente.

Conclusões

Apesar disso, o TDD não está morto

Eu não acho que o TDD esteja realmente morto, como acredita o David Heinemeier Hansson. Acredito que ele está apenas com raiva de não ter falado tudo isso antes.

TDD ainda faz sentido em alguns casos, como por exemplo na implementação de protocolos padrão ou de especificações que não vão mudar ao longo do tempo.

Não obstante, a declaração de David Heinemeier Hansson foi útil porque ajudou a libertar vários outros desenvolvedores, que puderam admitir que não usam TDD. David é um grande influenciador na comunidade de desenvolvimento de software, então muitas pessoas prestam atenção no que ele fala. Pena que ele levou tanto tempo para se expressar.

Outras manias de desenvolvimento de software para você repensar

Eu acho que o TDD seja apenas mais uma mania, modinha, à qual muitos desenvolvedores têm se apegado por muito tempo. Mas não é a única. Aqui estão algumas outras manias similares com as quais muitos ainda estão obcecados porque acreditam serem dogmas de religião. Eu não vou falar muito sobre essa lista porque não é o foco deste artigo, apenas reflita sobre elas:

• Tudo tem que ser um objeto
• Forçar-se a usar quantos Design Patterns forem possíveis
• Discutir estilo de formatação de códigos
• Programar tem que ser feito de forma bonita
• Contrate mais desenvolvedores para fazer programação em par (pair programming)

Sua opinião

Um pensamento importante que você deveria ter a partir deste artigo é que seu ponto de vista importa acima de todos os outros. Muitos seguem os “evangelistas de TDD” para, mais tarde, perceberem que não serve/não é bom para eles. Ainda assim, têm medo em admitir e nunca contestam abertamente.

Você não deveria tomar a opinião dos outros como leis a serem seguidas. Não vá cegamente pelo caminho e pelas ideias de outros. E isso inclui a mim. Não siga o que eu digo sem antes pensar no que é bom e no que é ruim para você. Se concorda comigo, ótimo. Se discorda, ótimo também. O que importa é que você reflita sobre outras opiniões, mas tire as suas próprias conclusões.

Se você apenas seguir as opiniões de outros e os seus projetos de software seguirem na direção errada, isso será culpa sua. Não vai adiantar dizer para o seu chefe e seus clientes que você seguiu a opinião de alguém – isso só vai fazer com que você pareça um bobo.

Então, se você discorda de mim e quer colocar o seu ponto de vista, comente neste artigo.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://www.phpclasses.org/blog/post/237-7-Reasons-Why-TDD-Failed-to-become-Mainstream.html