/Desenvolvimento

voltar
/Desenvolvimento

7 motivos por que TDD falhou em ser mais utilizado

PorManuel Lemos em

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

De 0 a 10, o quanto você recomendaria este artigo para um amigo?

 

Deixe um comentário! 83

83 comentários

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Achei os 7 motivos muito sem critério, TDD é caro se a sua equipe não tem experiencia, ele irá atrasar o seu projeto se os seus desenvolvedores não souberem o que tem que ser feito nos minimos detalhes, outro ponto, seus testes ficaram passado se você implementar novas funcionalidades e não realizar(ou atualizar) os seus outros testes, TDD é um assunto muito mais complicado que estes 7 motivos, se você é um programador com pouca experiência TDD vai te ajudar a escrever codigos muito mais coesos do que sem nada, para ter um bom TDD você realmente tem que seguir o SOLID, pelo o que eu li em outros foruns David Heinemeier aborda o TDD para desenvolvedores bem experientes nesta discussão.

    1. Marcio obrigado pelo seu comentário. Na verdade o artigo não é para dizer se o TDD é bou ou mau, mas sim explicar porque a vasta maioria dos desenvolvedores não escreve testes antes de implementar seu código.

      Independentemente se você concorda com os motivos, estes são alguns dos motivos pelos quais muitos desenvolvedores não aplicam na prática, e não tanto para comentar o que David Heinemeier Hansson acha. Ele é apenas um de muitos que usou e desistiu.

      Note que muitos desenvolvedores experientes até sabem bem o que é TDD, mas desistiram de aplicar pelos seus inconvenientes.

      Como o artigo explicou, no mundo ideal TDD seria uma solução ótima, mas não dá para um desenvolvedor experiente ignorar esses inconvenientes, que a bem da verdade diga-se que são mais do que aqueles que foram mencionados.

    2. Marcio, para que investir em algo que é “bem complicado” como você mesmo fala que é, se o problema a qual o TDD se propõe em resolver muitas vezes pode nem existir? Esta é uma das questões, muitas pessoas usam mais por moda, criando mais obstáculos técnicos no desenvolvimento do projeto e banalizando a analise de sistemas mais humanizada.

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

      Isso não é TDD, pois no TDD os testes nunca ficam ultrapassados, uma vez que são escritos ANTES.

      TDD pode até ter motivos pra não ser usado, mas esses 7 aí estão muito mal embasados.

  2. Isso vai longe, onde trabalho tetou-se implantar o TDD com a promessa de termos um código melhor e maior produtividade, a verdade foi que virou uma zona, nem o código melhorou tanto assim, e a produtividade foi pro buraco!

    1. Eu acho que o erro não foi da “modinha” em si e sim da falácia que alguns inventaram a respeito do TDD com a desculpa de implementá-lo a todo custo. TDD nunca foi promessa de “produtividade” (velocidade) e sim de “qualidade”. Não precisa ser um expert para saber que escrever testes consome mais tempo, logo, produtividade jamais será aumentada por conta disso. E isso de forma alguma tira os méritos de ter código coberto por testes.

      1. Não disse que ficar sem TDD ficará sem cobertura. Não confunda “testes” com a metodologia desenvolvimento si, no caso, o TDD. A cobertura pode vir de qualquer metodologia de verificação de especificação, seja ela TDD, BDD ou testes pós-desenvolvimento, como ocorre no processo tradicional.

      2. @Marcelo Rodrigues, ok você não ter falado que sem TDD não impede de ter cobertura. Mas também não confundo a metodologia orientada a testes com os “testes”, só li errado sua frase. Além de TDD, acho insanidade manter testes unitários em sistemas de informações, só faço teste funcional, que cobre testes reais.

  3. Sory TDD foi uma modinha que quiseram fazer todo mundo engolir
    O que é certo
    Projetos pequenos não deve fazer TDD pois fica caro
    Projetos médios devem ser localizados pontos importantes pois tem cabeça dura que até para um crud básico usa pqp
    Projeto Grande deve ser considerado mas com parcimónia e em cima de regra de negocio
    Este negocio de 100% coberto é bem problemático.
    Concordo com o Amigo Manuel e tenho pensamento muito semelhante
    So para lembrar (RR a melhor linguagem vai acabar com as outras, php com Singleton em tudo), o vira depois.
    Conselho par simonia em tudo.

  4. O TDD é lindo para empresas com um porte considerável, que pode manter profissionais mais experientes, porém, empresas de menor porte, startups apenas sonham com o TDD. Como foi dito, essa metodologia é cara e lenta, tudo o que uma pequena empresa precisa é: velocidade a com o menor custo possível.

    1. É verdade Diego, empresas de maior porte podem investir em ter mais desenvolvedores, e até especialistas em testes que realmente gostam de fazer essa atividade, porque para a maioria dos desenvolvedores criar testes é chato porque os testes não são o projeto em si, e apenas fazer os testes não dá para ver o projeto progredindo com rapidez.

      1. Se você acha isto: “…porque para a maioria dos desenvolvedores criar testes é chato porque os testes não são o projeto em si(…)” então acho que vc não é um profissional. Amadores não se preocupam com seu código, por consequência, acham que testar é bobagem.
        Sugiro urgentemente a leitura do livro “The Clean Coder – http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073“. Lá, diz que “Todo programado que se julgue profissional deve se preocupar com seu código, deve garantir que uma mudança não irá quebrar outras partes funcionando do software, e o mais importante, deve automatizar o teste de seus códigos”…..
        Nem abordei nada de TDD, só estou falando de testes que garantem um código funcionando. Nunca li tanta bobeira na minha vida em um artigo…. A qualidade do código no Brasil já é uma porcaria, e ainda vem um artigo deste. Imagina para um cara que está preocupado com seu código e agora começa a pensar: “Então, testar é coisa de moda e vai me gerar custos”………

        Sugiro muito a leitura dos livros: “The Clean Coder” e “The Clean Code”.. para mim, são referências mais do que obrigatório a qualquer programador que se julgue profissional. E com certeza, quebrará muitos paradigmas do que está escrito aqui. E não estou falando de TDD, estou falando apenas de bons códigos.

    2. Eu discordo que TDD é apenas para empresas de grande porte com profissionais experientes. Basta pegar qualquer fábrica de software, principalmente as que prestam serviços ao governo federal, para perceber que TDD nem é considerado, no fim das contas. Não estou discutindo os benefícios, mas minha opinião é que, depende muito da cultura e do projeto em si.

  5. O uso do TDD é muito específico, deve ser estudado e analisado com muito cuidado.

    Para um sistema de padaria que conta quantos pães foram vendidos no dia não tem muito uso, pois é algo muito básico, o software não sofre uma alteração toda semana ou todo mês como grandes sistemas. Neste caso a sua falta não traz prejuízo para o sistema e sim lucro no tempo de desenvolvimento.

    Eu trabalho num sistema grande que tem vários módulos, várias integrações com Web Services, novas funcionalidades semanalmente, novas integrações todo mês, alterações e implementações no código quase que todo dia. E quanto maior o sistemas fica maior é a dificuldade de mantê-lo.
    A falta de TDD aqui é um prejuízo extremamente alto na manutenção e duração do software. Quando um Web Service é alterado o tempo para a solução do problema é muito custoso. (Minha experiência)

    1. Felipe, penso que está havendo confusão. TDD não é meramente escrever testes para seu código, é escrever testes antes de escrever o código que pretende testar.

      Claro que é muito importante ter testes para partes críticas de sistemas que não podem falhar, mas isso não significa que você tem de escrever testes antes de tudo. Escrever testes antes de tudo é o que propõe TDD.

  6. Acredito que de um jeito ou de outro você vai ter que testar o código, nem que seja executando o programa e cadastrando alguma coisa para ver se da certo, se der errado você vai sair caçando o erro no código.

  7. Eu vejo por aí também uma modinha de escovar os dentes após as refeições que não dá pra aguentar. Desde que eu parei de escovar os dentes me sobrou mais tempo para focar em meu projetos pessoais. Alguns dentes estão caindo, mas eu adoro sopa.

    1. A analalogia com TDD não é essa. Deveria ser que o que TDD promove é que você comece a escovar mesmo antes de ter dentes na esperança de ter dentes que nunca vão ter cáries ou quaisquer outros problemas.

      A verdade é que por mais que você escove seus dentes, ao longo da sua vida, os dentes vão se detriorar porque existem outros fatores que causa detrioração que nada têm a ver com limpeza dos dentes.

      Da mesma forma o seu software sempre vai ter bugs por mais que você use TDD ou não, pois há sempre situações que causam bugs que não foram previstas nos seus testes.

  8. O título do artigo é bastante sensacionalista né? Mas por mais errado que esteja o artigo, vale à pena pelo simples fato de ter iniciado uma discussão.

    Então vamos por partes.
    O real problema por trás desta discussão toda não é o TDD em si, mas a sua má aplicação.
    Escrever testes antes e depois o código em si é uma boa prática? Sem dúvidas: te ajuda a projetar melhor suas interfaces, o modo como o código deveria funcionar e acaba virando uma especificação viva daquilo que precisamos implementar.

    Neste sentido, como estou pensando mais a respeito do que quero gerar, acaba que este tempo não é gasto, mas sim investido. Eu escrevo menos código, e aquele que escrevo, eu sei exatamente o que deve fazer pois o exercício de definição foi feito naquele teste.

    Claro: uma pessoa que fica escrevendo testes para getters e setters está transformando algo que deveria ser um ganho em um gasto indesejado. A pessoa tem de saber O QUÊ vale à pena ser testado. Levando isto em consideração, os testes que você escreve quando testa o que realmente importa acabam se tornando muito menores.

    Então, a pergunta que cabe aqui é a seguinte: o que é caro? Caro é quando meu esforço para obter algo me dá como resultado algo que vale menos que aquilo que investi.

    Se ao escrever meus testes antes melhorei minha visão sobre o que devia ser feito, e com isto escrevi um código funcional de melhor qualidade, ao mesmo tempo que tenho uma especificação funcional e dinâmica da coisa, a coisa não ficou cara, mas sim barata e passou a valer à pena, e muito.

    E se levarmos em consideração que o teste ainda me serve como garantia no futuro de que as modificações que meu código sofreu podem estar levando meu sistema a se comportar de maneiras diferentes daquelas para as quais foi projetado, então aquele meu custo é investimento mesmo: valeu mais à pena ainda!

    Então dizer que é caro, como mostrei acima, só se concretiza quando você não usa a coisa da maneira correta.

    Agora, vamos aos demais pontos.

    “Muitos desenvolvedores de reputação não usam” – Não: eu penso por conta própria. Se para eles não serviu, é devido ao contexto em que estão, não por que a coisa em si é ruim.

    “Muitos evangelistas de TDD não usam a coisa na maior parte do tempo” – qual a base para esta afirmação? E se não usam na maior parte do tempo, é sinal de que usam quando convém, certo?

    “TDD vai atrasar o lançamento do projeto” – de novo, discordo por causa dos benefícios que disse acima. Se te ajudam a pensar, é menos tempo que você gasta na tentaiva e erro e mais tempo que você ganha para poder lançar seu projeto com folga.

    “Você vai mudar seu projeto e os testes antigos ficam ultrapassados” – sim, ficam. Agora, o que ninguém menciona é que estes mesmos testes ultrapassados podem ser usados como base histórica para entender o desenvolvimento daquele sistema, o uqe ajuda HORRORES quando você lida com base legada.

    “Testar os meios da mais trabalho que testar os resultados” – de novo, há um equívoco aqui. O teste não é um meio, mas a especificação formal daquilo que será feito. É o resultado final na prática. A diferença é que você está vendo a coisa em isolamento.

    “Testes extensivos são chatos” – de novo, é aquela questão de saber O QUÊ testar. Se você testa o que tem valor real, não é chato, é necessário.

    1. Henrique, antes de mais parece que você está fazendo a mesma confusão de muitos que contestam o artigo.

      TDD é fazer testes sempre antes do código que você pretende testar. Se você cria testes para código que já escreveu, isso não é TDD.

      TDD é desenvolvimento conduzido por testes. Se você escreve testes depois, isso é testes conduzidos por código.

      Posto isto, o que o artigo se refere é escrever testes antes de escrever o código.

      Em lado nenhum é dito que escrever testes para seu código é algo ruim.

      Para além disso, se você precisa escrever sempre testes antes para criar um bom design para o seu software, isso reflete insegurança na sua própria capacidade de criar bons designs de software sem se apoiar em testes.

      Seja como for, quando se fala de custo de software tem a ver com o tempo de desenvolvimento. Se você tem de escrever testes antes de escrever o código, com certeza demora mais tempo, não há milagres, logo é mais caro.

      Isso não quer dizer que não valha a pena em alguns casos, como por exemplo quando você está implementação de uma especificação claramente definida, como é o caso de protocolos definidos por organizações de padronização. Isso está explicado no artigo.

      > “Muitos desenvolvedores de reputação não usam” – Não: eu penso por conta própria. Se para eles não serviu, é devido ao contexto em que estão, não por que a coisa em si é ruim.

      Isso foi o que eu escrevi no fim do artigo. Leu até ao fim?

      > “Muitos evangelistas de TDD não usam a coisa na maior parte do tempo” – qual a base para esta afirmação? E se não usam na maior parte do tempo, é sinal de que usam quando convém, certo?

      Por exemplo o próprio David Heinemeier Hansson era um evangelista que passado anos admitiu que não usava mais. Ele próprio falou que conhecia mais evangelistas nessa situação. Você acompanhou a história?

      > “TDD vai atrasar o lançamento do projeto” – de novo, discordo por causa dos benefícios que disse acima. Se te ajudam a pensar, é menos tempo que você gasta na tentaiva e erro e mais tempo que você ganha para poder lançar seu projeto com folga.

      Parece que você está confundindo os fatos com a sua visão dos beneficios. Escrever testes antes de escrever o código demora mais tempo que escrever o código. Isso não depende se você vê ou não beneficios em escrever testes antes. Escrever mais código vai atrasar o lançamento de qualquer projeto, esse é o fato.

      > “Você vai mudar seu projeto e os testes antigos ficam ultrapassados” – sim, ficam. Agora, o que ninguém menciona é que estes mesmos testes ultrapassados podem ser usados como base histórica para entender o desenvolvimento daquele sistema, o uqe ajuda HORRORES quando você lida com base legada.

      Desculpe, mas o que mantém o histórico do seu projeto é usar um sistema de controle de versões, não ficar mantendo testes que vão ficar obsoletos.

      > “Testar os meios da mais trabalho que testar os resultados” – de novo, há um equívoco aqui. O teste não é um meio, mas a especificação formal daquilo que será feito. É o resultado final na prática. A diferença é que você está vendo a coisa em isolamento.

      Antes pelo contrário. Testar os meios é ficar criando testes para toda e qualquer função do seu projeto. Testar os resultados é verificar se o resultado de um conjunto de componentes dá o resultado esperado. Você não precisa testar cada funçãozinha de cada componentezinho do seu projeto. Você mesmo admitiu que é descabido ficar testando getters e setters. Parece que está se contradizendo.

      > “Testes extensivos são chatos” – de novo, é aquela questão de saber O QUÊ testar. Se você testa o que tem valor real, não é chato, é necessário.

      Ah, então você está concordando com esta frase e a anterior que indica que é mais razoável testar os resultados do que ficar testando os meios, pois os resultados é o que importa.

      Enfim, no fundo muitas pessoas como você até concordam com o artigo, só talvez não tenham entendido bem o que foi explicado e aí se predispuseram a contra-argumentar. Para você e todo mundo nessa situação recomendo uma releitura.

      1. Oi Manuel,

        então antes de mais nada eu te sugiro dar uma boa relida no que escreve, pois bem mais de um apessoa aqui nesta thread entendeu o mesmo que eu. Se isto ocorreu, é por que a comunicação está deficitária, ou seja, o artigo está mal escrito. Especialmente quando você topa com uma seção inteira no meio dele entitulada “Então, por que TDD falhou?”.

        Agora, vamos aos pontos, que você me respondeu

        “Para além disso, se você precisa escrever sempre testes antes para criar um bom design para o seu software, isso reflete insegurança na sua própria capacidade de criar bons designs de software sem se apoiar em testes.”

        Errado: é apenas mais uma ferramenta que você pode usar, como UML, por exemplo. Isto não reflete insegurança alguma, pelo contrário.

        Sobre a história do DHH, acompanhei de perto, e, novamente, o mesmo ponto volta Manuel: não há uma base sólida para dizer como você diz que muitos afirmam ser bom e não o usam. Você só mostrou um exemplo, o do DHH, e mesmo assim ainda é muito pouco para que algo possa ser dito.

        Outro ponto interessante no seu comentário Manuel: “Desculpe, mas o que mantém o histórico do seu projeto é usar um sistema de controle de versões, não ficar mantendo testes que vão ficar obsoletos.”

        Errado: controle de versões é uma ferramenta para este fim porém não a única possível: testes também podem ser usados como tal e são usados em diversos projetos de forma extremamente bem sucedida.

        E a idéia Manuel, não é te refutar ou coisa similar. É apenas uma discussão saudável a respeito do assunto, tal como inclui no início do comentário. O que sugiro é que você também releia o que escreveu, pois seu texto, tal como comprovado pelos comentários aqui presentes, gerou diversas (nas suas palavras) más interpretações

      2. Acho mais é que os programadores em geral pouco entendem de TDD e se credenciam a falar o que não sabem. O artigo está muito bem escrito para quem sabe o que é o TDD.

  9. Manuel, você nem ao menos leu os textos do DHH sobre testes (sabia que foram mais de um?) e muito menos acompanhou o debate entre DHH, Kent Beck (ao menos você sabe quem é?) e Martin Fowler.

    Vergonha para você, que colocou seu nome nesse amontoado de asneiras, vergonha para o iMasters, que endossou essa vergonha.

  10. Vou me permitir contestar cada um dos “argumentos”. Vejamos:

    1. TDD é caro
    Talvez TDD aumente o custo de desenvolvimento. Mas ele, com certeza, reduz o custo de manutenção. Como “desenvolver” ocorre uma vez e “manter” ocorre ~para sempre~. Me parece racional, economicamente, assumir que vale a pena pagar o preço de desenvolvimento em favor da manutenção.

    2. TDD vai atrasar o projeto
    Sério, mesmo, que é mais barato rodar a aplicação sempre? Eu passo dias, as vezes, sem precisar levantar minhas aplicações para ver se tudo está funcionando (trabalho em back-end). Quando rodo, vejo que tudo está funcionando.

    3. Você vai mudar o seu projeto…
    E o “Open-closed principle”?!

    4. Testar os meios dá mais trabalho que testar os resultados
    Testes de unidade x Testes funcionais …

    5. Testes extensivos são chatos
    Eu tenho uma biblioteca com mais de 900 testes escritos para ela. Confesso que fico agradecido e não acho nada chato receber feedback imediato (em menos de 10 segundos) de que tudo continua ok. Confesso que acho até divertido ver uns “40 testes” quebrarem quando cometo algum erro idiota.

    6. Muitos evangelistas de TDD não usam a metodologia na maior parte do tempo, mas não admitem isso
    Isso é verdade. Mas, o que isso tem haver com meu desejo de ser eficiente. Sério que devo considerar sério um desenvolvedor que faz uma coisa só porque disseram que é bonito fazer?

    7. Muitos desenvolvedores com boa reputação não usam TDD
    Ok. Novamente. :D

    1. Elemar, acho que não ficou claro para você o intuito do artigo. O artigo apresenta motivos para o fato de TDD não ter emplacado e nãoi ser usado pela esmagadora maioria dos desenvolvedores.

      Isso não significa que não existam desenvolvedores que não usem porque acreditam piamente ser uma coisa boa para se usar. Aliás o artigo termina falando isso. Cada desenvolvedor deve decidir por si o é bom ou não para cada um.

    1. Não, a ideia não foi criar polêmica, se bem que não tem como evitar, dado que existem pessoas com opiniões tão apaixonadas sobre o assunto,

      A ideia foi esclarecer que certas metodologias, por mais benéficas que pareçam em determinadas circunstâncias, elas têm inconvenientes que não podem ser ignorados.

  11. Curioso você citar o artigo do DHH e linkar os vídeos da série “Is TDD dead?” e escrever algo não é a opinião de nenhum dos 3 envolvidos.
    O DHH fala de não usar TDD, mas em momento algum ele fala de escrever código de produção sem escrever testes! O que contradiz o seus motivos 1, 2, 3, 4 e 5.

    1. David, então acho que não ficou claro para você o intuito do artigo. A relação que o artigo tem com esse debate, é apenas o fato de que o DHH admitiu que não usa TDD apesar de ter sido evangelista há muitos anos.

      Este artigo é sobre o fato de que TDD falou em ter adesão generalizada dos desenvolvedores, mesmo por aqueles que entendem o que é TDD, como o próprio DHH.

      Seja como for você também está confundindo usar testes com TDD. Como já escrevi acima várias vezes escrever testes por si só não é TDD se você não escrever os testes antes de escrever o código que pretende testar.

      Enfim, mais uma vez você comprovou que muitas pessoas que dizem entender o que é TDD, confundem TDD com meramente escrever testes. Vale a pena você rever esses conceitos para evitar ficar criticando algo que você não entende.

  12. Na boa… acho que esse foi o pior artigo que eu ja li na minha vida.
    É incrivel como o artigo só foi piorando.
    Espero nunca trabalhar com uma pessoa que pense assim.

  13. Com todo respeito ao autor, mas sou obrigada a discordar. TDD é eficiente sim, mas como todo aprendizado levasse tempo. O TDD é custoso no início, mas com a prática tem seus benefícios. E acredito na existência dos testes para garantir a qualidade de funcionalidades co-relacionadas. Uma mudança pode afetar a outra e os testes garantem isso. Infelizmente este artigo não me diz nada.

    1. Prsicila, parece que existe um mal-entendido comum de que TDD é apenas criar testes. Se você não escrever testes antes de criar o código que pretende testar, isso não é TDD.

      O artigo se refere apenas a TDD como prática que determina que os testes têm ser escritos antes do código, pois TDD é desenvolvimento conduzido por testes, e não testes conduzidos pelo código.

      Você pode escrever testes para seu código depois deste ter sido escrito e continuar a beneficiar da existência de testes, não precisa escrever os testes antes como apregoa TDD.

      1. Pode escrever testes depois sim. No entanto qual garantia vc tem de estar cobrindo todas as arestas. Será que algo não pode cair no esquecimento ou deixar de ser testado simplesmente pq foi feito depois? Td bem que existem os testes de cobertura, mas será que todos utilizam desta prática? E a cobertura, garante que cada regra funcione como deveria? Eu entendi seu ponto de vista, mas discordo. Pq pratico TDD no dia a dia e sei que funciona, apenas tive que praticar muito pata atingir meu nível de produtividade atial.

      2. Priscila, acho que não ficou claro para você o que eu expliquei. Você escreve testes quando quiser, antes ou depois de ter escrito o código a testar.

        O que se passa é só é TDD quando você começou escrevendo os testes antes do código a ser testado. Caso tenha dúvidas sobre o que é TDD, veja esta definição na Wikipedia.

        http://pt.wikipedia.org/wiki/Test_Driven_Development

        O que importa é que o que o artigo comenta é a prática de ter de escrever testes primeiro antes de escrever o código a ser testado.

        Então você está discordando de algo que não foi comentado, pois em lado nenhum o artigo diz que escrever testes depois de ter escrito o código a testar é algo ruim, antes pelo contrário, o artigo explica que é isso que muitos desenvolvedores fazem, criam testes depois de ter escrito o código que pretendem testar, pois nessa altura já têm um design estabilizado e dificilmente vão precisar de mudar os testes pois a especificação do software não deverá mudar significativamente.

      3. Manuel, com todo o respeito. Sério mesmo que vc quer me mandar um link explicando o que é TDD? Enfim, o seu artigo fala sobre os possíveis contras sobre praticar o TDD, e eu não concordo com eles. Muito obrigada pela sua explicação, mas estudo muito sobre testes e gosto disso. Não falo sobre isso simplesmente por que é legal. Que fique o artigo aí para que opinem o que é necessário
        Meu comentário não foi muito diferente dos demais. Foi a minha opinião sobre os pontos de falha que vc levantou e eu discordo.

      4. Mas, resumindo, o que este artigo transmitiu de mensagem foi: “Que fazer testes é ruim, e que o TDD é falho por causa disso”

        No artigo -> Eu acho que o TDD seja apenas mais uma mania, modinha, à qual muitos desenvolvedores têm se apegado por muito tempo

        Não concordo com isso. Implementar seu código a partir dos testes, auxilia o desenvolvedor em diversos cenários, que já comentei antes em meu primeiro comentário. Dá uma preguica gigantesca escrever testes depois do código, e por isso, muitos acabam deixando de lado, e matamos isso com a prática do TDD. O atraso nos projetos, é relativo. Com a prática, a produtividade melhora. E outra, um sistema bem testado, evita muita manutenção.

        No artigo -> Você vai mudar os seus projetos, e os testes antigos serão ultrapassados
        Obviu. Se teve mudanca, os testes precisaram ser ajustados para a nova mudança.

        Enfim, acho que todos já falaram bastante.

        Não me prolongarei mais. Acho que já expressei minha opnião o bastante =D

        Mas, parabéns pela coragem de escrever um artigo deste.

      5. Priscila, não sei se vale a pena insistir, se você continua achando equivocadamente que o artigo está dizendo que escrever testes é ruim.

        O artigo apenas comenta sobre a prática de escrever testes sempre antes do código que se pretende testar. Isso sim é TDD.

        TDD é desenvolvimento conduzido por testes. Se você escreve testes para código que já foi implementado e chama isso de TDD, receio que precise rever o seu conceito sobre que é TDD ou não. Por isso mandei um link de uma página com a definição de TDD que não fui eu que escrevi.

        A vantagem de escrever testes depois é que o seu design já está mais estabilizado, e por isso as chances de mudar os testes são menores, ou seja, dificilmente vai ter retrabalho e perder tempo a refazer testes porque decidiu mudar o design.

        Não adianta ignorar que o uso de TDD atrasa os seus projetos. Mesmo que você melhore e reduza esse atraso, você não consegue eliminar o atraso.

        Não sei se é o seu caso, mas muitos desenvolvedores fanáticos por TDD, não valorizam muito o tempo adicional necessário para fazer testes antes para tudo, porque eles não sentem a urgência que os negócios precisam andar para os produtos poderem ser lançados ao mercado o mais rápido possível.

        A verdade é que muitos desenvolvedores não entendem nada de negócios e só se ligam em aspectos técnicos. Porém o software é que deve servir negócios e seus requisitos.

        O que acontece é que muitos desenvolvedores só se apercebem do custo de práticas caras como TDD, depois que um dia decidem empreender e ser donos dos próprios negócios, e descobrem que se você demora demasiado desenvolvendo seus produtos, a sua empresa pode morrer antes do software sequer ficar pronto.

      6. Priscila, em sistemas de informações o que garante que a regra funciona antes de desenvolver são os frutos de um bom entrosamento entre os analistas de sistemas e os clientes que gerenciam o negócio. A geração atual infelizmente quer tornar o desenvolvimento muito mecanizado.

  14. Na boa, no começo do artigo achei que fosse um artigo irônico ou pegadinha. O autor original do artigo definitivamente nunca se aprofundou em TDD. Todas as razões que foram dados estão mais pra ‘achismos’.

  15. Olha concordando ou não com alguns argumentos meus parabéns ao Manuel realmente gostei muito de ter outra visão sobre o assunto, e de alguns comentários com argumentos pois só achar ruim sem argumentar é ser covarde e se esconder, espero sinceramente ter mais conteúdos divergentes como este na imasters para que possamos juntos evoluir mais a web sempre com argumentos e com a cabeça aberta sem nenhum tipo de censura.
    Minha Opinião TDD tem vantagens mas realmente é Chatinho de fazer pacas.

  16. Nossa! Que artigo zuado. Quanta desinformação. Do jeito que você fala, se eu não soubesse o que é TDD já ia imaginar uma reunião de kick-off, com o pessoal montando cronogramas waterfall de um projeto e um dos itens seria: escrever TODOS os testes do projeto.

    E TDD não é anda disso. Não é escrever os testes 1 semana, 1 dia ou 1 mês antes. É escrever um teste IMEDIATAMENTE antes de você fazer qualquer coisa.

    E TDD também não é escrever testes complexos, com trocentas linhas e asserts. Afinal, se está difícil de testar, o código/abstração não deve estar legal.

    E na verdade, se o teste é feito antes ou depois, isso faz pouca diferença. Embora escrever os testes antes lhe ajude a pensar melhor em 2 coisas:
    1 – A API/abstração. Se você já começa imaginando chamar um método que precisa passar 10 parâmetros isso deveria acender uma luz amarela…
    2 – Evita a preguiça do tipo “Agora que já está funcionando não vou fazer testes”.

    A verdade é que ter testes sempre se paga. E o custo de ter testes é muito pouco comparado ao custo total do projeto. Ter 50% de cobertura de testes não vai aumentar o seu custo em 50%.

    1. Bjornn, parece que você não entendeu bem o artigo. Em lado nenhum diz que TDD é escrever todos testes de todas partes do seu projeto antes de escrever o código do projeto em si.

      O artigo também não diz para você não escrever testes para o seu projeto,

      Recomendo que leia o artigo de novo de preferência sem intenção de arranjar motivos forçados para criticar.

      1. Manuel, esse trecho aqui é bem dúbio: “Se você precisa escrever testes para tudo antes de começar, obviamente o seu projeto vai levar mais tempo ou usar mais desenvolvedores.”

        Esse outro trecho aqui é bem otimista: “O fato é que você apenas vai quebrar algo se fizer uma mudança, ou mudar as dependências de forma significativa”.
        Afinal você pode fazer algo que já nasce quebrado/errado. Ou mesmo quebrar algo a partir uma minúscula mudança.

        Esse tópico aqui é a lei da vida: “3. Você vai mudar os seus projetos, e os testes antigos serão ultrapassados”. Afinal, o código que escrevi hoje e resolve o problema hoje pode ter que ser modificado amanhã pois será considerado ultrapassado também. Logo, é natural acontecer isso com testes também.

        Quanto ao tópico 4, isso vai depender dos vários tipos de testes. Se você está focado no resultado talvez você prefira um teste de integração/aceitação. Talvez até usando um selenium, para uma aplicação web, por exemplo. Quanto as partes pequenas, eu até acho mais fácil testar 1000 pequenos componentes com testes pequenos e simples e ter uma quase certeza de que eles vão funcionar corretamente quando plugados para montar um componente maior.

        Concordo com isso: “5. Testes extensivos são chatos”. Mas isso é mais uma questão de definir uma granularidade correta para o que deve ser testado e o que não deve ser testado…

        “6. Muitos evangelistas de TDD não usam a metodologia na maior parte do tempo, mas não admitem isso”. Ok não escrever testes necessariamente antes de desenvolver, mas devem haver testes feitos pelo desenvolvedor…

        “7. Muitos desenvolvedores com boa reputação não usam TDD”. Se for olhar a questão de escrever o teste realmente antes, ok. Mas se analisar a questão de não ter testes por causa de custos, é tipo ter bons motoristas que não usam o cinto de segurança…

        Eu não estou arrumando motivos forçados para criticar, mas acho que os argumentos foram fracos.

      2. Bjornn, até entendo que você tenha a lido a frase e lhe tenha parecido que eu estaria dizendo que você teria de escrever todos testes de todo projeto antes de escrever o código do projeto em si.

        Se eu tivesse querido dizer isso, seria uma alegação tão absurda que acredito que isso lhe deveria ter despertado a sensação de que talvez você não tivesse entendido bem.

        Seja como for, agora que já esclareci que com certeza não foi isso que quis dizer, espero que esteja bem entendido.

        De resto, entenda que pelo fato de usar TDD, ou seja escrever testes antes de escrever o código a ser testado, isso não garante que o seu código não nasça “quebrado”. Da mesmo forma, não usando TDD, não significa que o seu código vai nascer necessariamente quebrado.

        Como texto explica, o problema de escrever testes prematuramente, é que quando precisar de mudar o design, você vai perder o tempo esforço de ter escrito testes que se tornaram obsoletos.

        A verdade é que mesmo usando TDD, você não consegue evitar a necesaide de mudar o design do seu projeto várias vezes, especialmente no principio do seu projeto, porque ninguém é tão bom para criar um design perfeito logo de cara mesmo que use TDD, especialmente em sistemas complexos.

        De resto você parece estar concordando que não é preciso testar todos os meios se você testar os fins, e assim economizar muito tempo fazendo micro testes para tudo.

        O problema é que TDD diz que você tem sempre de escrever testes antes para todo código que vai escrever para o seu projeto. Na prática ninguém faz isso, acho que nem o Kent Beck que definiu o que é TDD.

        De resto o artigo em lado nenhum diz que você não deve escrever testes. Não faria sentido se eu tivesse dito isso, quando eu escrevo testes para alguns componentes que publico já desde 1999, muito antes de Kent Beck definir o que é TDD.

        Portanto, como eu disse eu uso e recomendo usar testes quando faz sentido, tal como recomendo usar cinto de segurança sempre porque faz sentido usar sempre.

        Por fim, mais uma vez o artigo não era argumentar contra o uso de TDD, mas sim explicar porque a esmagadora maioria dos desenvolvedores não usa, por isso o título do artigo é “7 motivos por que TDD falhou em ser mais utilizado”.

        http://www.phpclasses.org/browse/author/1.html

  17. Quando você vê o autor dizendo repetidas vezes nos comentários que “você não entendeu bem o artigo” é sinal de algo bem simples: a qualidade da escrita está ruim pois não conseguiu o fundamental que é transmitir uma idéia.

    1. Henrinque, também me passou pela cabeça que uma ou outra coisa pudesse estar a ser mal entendida porque diferentes pessoas interpretam o significado de forma diferente. Afinal de contas nenhuma pessoa escreve de forma tão perfeita um texto longo sem dar aso a mal-entendidos. Para isso existem os comentários para esclarecer.

      Porém ao analisar as respostas noto outra coisa que você mesmo acabou de demonstrar. Quando você diz que eu estou dizendo que “TDD falhou” você está mostrando que apenas leu menos metade do título do artigo. O título diz “TDD falhou em ser mais utilizado”, o que é bem diferente de dizer apenas que “TDD falhou”.

      Por isso, o que me parece que as pessoas que reclamam do artigo porque intrepretaram de forma equivocada, talvez estejam tendo uma reação emocional ou talvez por serem jovens da geração mais recente, fazem tudo à pressa e não se dão ao trabalho de ler os textos completamente com atenção.

      Nesse caso, não posso fazer nada a não ser recomendar ler de novo com atenção.

      O fato de existirem várias pessoas com o mesmo problema de interpretação por não lerem direito, só reforça que pode ser um problema de geração.

      Ainda estes dias apareceu um artigo no Youpix falando da “geração só a cabecinha”, que são os mais novos que não entram nos contextos com mais profundidade porque têm pressa e acabam perdendo porque não tiveram paciência para se inteirar dos detalhes.

      http://youpix.virgula.uol.com.br/colunistas/geracao-cabecinha/

      1. Neste caso discodo de você Manuel, pois a quantidade de pessoas dizendo a mesma coisa sobre seu texto é bem grande, e muitos que estão comentando o mesmo que eu são pessoas extremamente competentes e que também escrevem.
        Ao invés de dizer que a culpa é do outro, seria mais interessante fazer uma auto reflexão.
        No caso do seu texto realmente é um problema de escrita. Normal, acontece. É bola pra frente e escrever outro melhor agora.

      2. Henrique, não sei se reparou, mas você está confirmando o que eu disse.

        Se reler a minha primeira frase com atenção especialmente onde digo “também me passou pela cabeça”, você vai entender que eu já fiz essa reflexão logo.

        Outro detalhe é que alguns que se manifestaram para discordar do que eu disse, dificilmente dão o braço a torcer, quando tento explicar melhor. Ou seja, são pessoas por sistema teimosas e polêmicas. Por mais que eu tente esclarecer, elas sempre vão argumentar algo contra, porque entendem que debate é uma competição que têm de ganhar a todo custo. Besteira, debate é troca de ideias.

        Outro detalhe é que parece que você não está notando que muitos dos que se manifestaram, entenderam bem o que eu disse e estão concordando. Portanto se uns entendem e concordam, e outros não entendem e discordam, tendo em conta que todos leram o mesmo artigo, o problema não parece estar no artigo em si, não concorda?

        Como eu disse, eu acho natural que pessoas diferentes entendam as coisas de forma diferente, dado que é dificil escrever um artigo longo sem ambiguidades. Eu não acho que seja uma questão de culpar quem escreve ou quem lê.

        Mas se depois de eu explicar melhor nos comentários os mal-entendidos, algumas pessoas ainda continuam de má vontade forçando a barra para discordar, convenhamos que o problema já não está no artigo.

        Portanto, penso que não faz sentido escrever outro artigo, porque as mesmas pessoas vão continuar com a mesma atitude.

  18. E sabem o que é mais interessante nestes comentários aqui?

    O autor diz que as pessoas não entenderam o texto dele. No entanto, o que elas estão criticando são os pontos apontados pelo AUTOR como as principais causas pelas quais as pessoas não adotarem TDD.

    Então, nos comentários o autor diz que não está dizendo que TDD é ruim, mas nos comentários, busca justificar todos aqueles que apontam problemas nas justificativas apresentadas.

    Ou seja, acaba que no final das contas o texto era sim uma crítica ao TDD. Basta que você leia o texto junto com os comentários pra comprovar isto.

    Do ponto de vista hermeneutico é bastante interessante. :)

    1. Henrique, se você reler o título que diz “7 motivos por que TDD falhou em ser mais utilizado” talvez note que o artigo é mostrar os motivos pelos quais a maioria dos desenvolvedores não quer usar TDD sempre.

      Isso não significa que para uma minoria dos desenvolvedores faça sentido usar sempre TDD.

      Se você ler mais abaixo, o artigo ainda diz que ao contrário da opinião de DHH, TDD não morreu porque faz sentido usar em determinadas situações para as quais existe uma especificação padronizada.

      Acabei de publicar outro artigo onde digo isso de novo a propósito da recente iniciativa do Facebook para criar uma especificação formal para a linguagem PHP. Aí sim faz todo sentido criar testes antes de implementar novos recursos em novas versões da linguagem para os quais já existe uma especificação.

      http://www.phpclasses.org/blog/post/241-PHP-Core-Developers-versus-Facebook-Round-3–The-PHP-Specification.html

      Portanto este artigo traduzido pelo iMasters, não era tanto uma crítica ao TDD, mas sim mostrar que a maioria dos desenvolvedores não usa TDD sempre pelos motivos apresentados.

  19. Para quem se interessar sobre TDD, vantagens, desvantagens, etc, eu recomendo o livro do Maurício Aniche, da casa do código. O livro se chama “Test-Driven Development: Teste e Design no Mundo Real”

  20. Concordo plenamente em relação a projetos de sistemas de informação. Espero que isso faça parte dos religiosos acordarem para a realidade, onde o foco é atender a solução fim para o Negócio e não ficar brincando de tecnologia. Deu certo só para quem ficou vendendo palestras, cursos e livros.

  21. Olá, acho que no artigo, assim como na série de vídeos “Is TDD Dead?”, não houve um foco majoritário na prática do TDD em si, mas sim na questão: criar testes unitários, ou não?

    1. Rafael, não tenho a certeza se é isso que está perguntando, mas penso a questão maior é se os testes devem ser sempre criados antes de criar o código a ser testado, ou podem ser criados depois.

      Outra questão importante, é se você precisa mesmo se dar ao trabalho de criar testes para a maior parte do seu código ou apenas para o código que gera resultados importantes que não podem falhar?

  22. Aqui o autor citou TDD como religião e é o que realmente está parecendo, pois os “religiosos” estão todos atacando.

    Sobre TDD, ele ajuda muito sim, mas problema dele é fazer com que todos os programadores o usem e usem da maneira correta, pois não adianta escreve um teste e ter uma falsa sensação de segurança ( qualidade ).

    Acho que se todos que postaram aqui criticando a matéria do autor ( que se parece com o Geraldo Magela, vide Google ), se tentasse ao menos melhorar “filosofia” do TDD, com certeza dariamos um grande passo ( #ficadica, kkkkk )

  23. É incrível como muitos desenvolvedores se acham o suprassumo da sabedoria, ao quererem ditar como os demais desenvolvedores devem trabalhar.

    Cada metodologia tem sua aplicação e não dá pra chamá-la de boa ou ruim, apenas de inadequada ou adequada para um problema específico. Para cada projeto, cabe aos analistas entenderem o problema e as necessidades do cliente e definirem se vale mais a pena um modelo em cascata, espiral, algum método ágil, TDD, DDD, etc., etc., etc.

    TDD combina bem **no geral** com desenvolvimento de frameworks, linguagens (compiladores), protocolos, APIS, já que a baixa mutabilidade é intrínseca e não há tanto controle dos inputs esperados.

    Ao desenvolver aplicações mais dinâmicas, nas quais os requisitos mudam toda hora, é um tiro no pé ser tão burocrático. Grandes são as chances de que os requisitos mudem muito antes de um bug ser descoberto.

    A razão para o TDD não é mais utilizado é apenas UMA: seu escopo é limitado.

    1. @Henrique, 100% apoiado também. Insanidade usar TDD em sistemas de informações. Infelizmente muitos se preocupam mais com questões desnecessárias de TI por achar “cool”, do que se preocupar com a evolução do sistema para Negócio.

  24. Olá Manuel!

    Eu concordo totalmente com tudo o que foi dito e ainda acrescento que outra “modinha” ou “mania” como você chamou que vive em alta, mas que não presta, é o famoso scrum (ou diria scum).
    O que acontece é que os evangelistas de todas essas bobagens geralmente são os que ensinam os novos programadores quando entram no ramo, então tudo o que a pessoa aprende quando está no início ela tende a encarar como verdade com todas as forças.
    Eu vejo muita gente aprendendo a programar direto com python e java por exemplo, e logo aprendem orientação a objetos, e levam OO como o núcleo de toda a programação, mas nunca tiveram um real contato com uma linguagem procedural.
    Já os mais antigos ou quem começou com C, Fortran, etc, tem a mente mais aberta e enxergam OO de outra forma, sabem distinguir quando pode ser interessante utilizar e quando não, além de não transformar “tudo” em objetos, como você bem citou.

    Um abraço!

    1. Jackson Benete, concordo plenamente sobre essas modinhas e o quanto hoje infelizmente a religião invadiu a TI, onde as pessoas são doutrinadas por esses evangelizadores a usar algo não deixando as pessoas se sentirem a vontade para criticar e analisar se aquilo vai mesmo trazer retorno com saldo positivo para o projeto do cliente. É tudo para manter a valorização da moda e poder ganhar dinheiro com palestras.

  25. Manuel, após ler seu artigo e todos os comentários, acho que entendi seu ponto de vista.

    O fato de TDD ser bom ou ruim não está no debate, o que foi apresentado são os motivos alegados pelos desenvolvedores para a não prática de TDD.

    Eu vejo que os argumentos expostos são amplamente e rapidamente refutáveis, então o problema passa a ser outro, adotar TDD atualmente não é prático. Neste ponto concordo se considerarmos as diversas tecnologias e que os recursos para realizar essa prática requer estudo e conhecimento, algo que não se aprende junto com o aprendizado da linguagem.

    Apesar das excelentes iniciativas de DojoRio, Uncle Bob, Kent Beck, Mauricio Aniche, etc, o fato é que para o publico desenvolvedor em geral, testes unitários ainda é algo mal vendido, mal difundido, doloroso, então imagina TDD é muito pior.

    Eu pratico TDD todos os dias e durante o processo de aprender o seu uso, percebi que não é algo tão simples e intuitivo, requer alguma capacidade de abstração, qualidade que nem sempre é cultivado pelos profissionais.

    1. Sim Sidney, mas é preciso entender que não são apenas as pessoas que acham complicado que não usam, são também pessoas que já usaram e até evangelizaram outros para usar, e depois chegaram à conclusão que até atrapalha se tentar usar sempre. Esse é o caso do DHH. Mas ele mencionou mais coisas que não mencionei neste artigo.

  26. Primeiro eu gostaria de parabenizar o autor por investir o tempo para organizar suas ideias e compartilhar. Concordo plenamente quando diz que temos que criticar o que os outros sugerem ao invés de seguir cegamente. Novamente parabéns pela coragem em manifestar sua opinião e atenção em retornar cada comentário.

    Gostaria de ponderar diversos pontos, assim como muitos já fizeram.

    1) TDD é caro
    É fácil encontrar situações que ele é caro, em lugares que não cabe teste unitário ou até mesmo para pessoas trabalhando inicialmente com essa metodologia, pois é uma quebra de paradigma muito grande.
    De toda forma é fácil encontrar exemplos onde ele é mais barato. Todo desenvolvedor que busca qualidade do que produz, teste seu código. Isso pode ser feito entrando no sistema e configurando N ambientes (para a variação de situações necessárias) ou fazendo essa situação via teste unitário ou até mesmo via TDD.
    2) TDD vai atrasar o lançamento do seu projeto
    Permita-me discordar e da forma exposta ficou parecendo crítica a Teste Unitário e não apenas a TDD (Teste antes). O teste unitário serve para garantir que um comportamento anterior seja conhecido e respeitado. Isso não quer dizer que o sistema não deva evoluir, mas o TU ajuda que ao evoluir um método ou funcionalidade, deva ser repensado alguns comportamentos esperados.
    3) Você vai mudar os seus projetos, e os testes antigos serão ultrapassados
    Novamente uma crítica que não foi ao TDD e sim a Testes Unitários de uma forma geral. O Teste unitário ajuda a você a conhecer que existe uma expectativa ou situação esperada do seu sistema. Se ele evoluiu, basta evoluir o teste unitário.
    Por isso o teste unitário tem que ser bem feito e bem direcionado.
    4) Testar os meios dá mais trabalho que testar os resultados
    Novamente uma crítica que não foi ao TDD e sim a Testes Unitários de uma forma geral. Não consigo concordar e nem discordar, pois não entendi muito.
    Para mim o assunto pareceu mais refatoração, que eu acho importante, deve ser feita de tempos em tempos com cuidado para evitar reflexos negativos (Bugs). Teste unitário evita acontecer reflexos negativos.
    5) Testes extensivos são chatos
    Novamente uma crítica que não foi ao TDD e sim a Testes Unitários de uma forma geral.
    Teste unitário não é bala de prata e em alguns casos teste caixa preta é melhor (No caso de IO, Base de dados, etc). De toda forma, existem casos que o teste unitário é o melhor a ser feito.
    6) Muitos evangelistas de TDD não usam a metodologia na maior parte do tempo, mas não admitem isso
    Não acredito que o TDD deva ser usado em todos os casos. Não acredito que o Teste Unitário deva ser utilizado em todos os casos.
    De toda forma acredito que o TDD e Teste unitário tem muita aplicação e deveríamos conhecer.
    Alguém não ser íntegro ao discurso ou fazer mal feito não é motivo para condenar uma forma de trabalho.
    7) Muitos desenvolvedores com boa reputação não usam TDD
    Concordo plenamente!
    Uma coisa é usar TDD e TU em todo e qualquer caso, que também acho bobagem. Outra coisa é saber quando se aplica e utilizar.

    1. Mateus, obrigado pelo seu comentário. O problema penso ser o fato quem defende TDD muitas vezes alega que TDD tem de ser usado sempre, ou seja, todo desenvolvimento começa por escrever testes. É que se você não começa escrevendo testes, isso já não é TDD. É nesse contexto que são explicados os argumentos pelo qual TDD não se tornou dominante.

      Usar TDD em alguns casos faz sentido. Agora usar sempre, são muito poucas as pessoas que fazem isso.

    2. Concordo com o autor, mesmo ele querendo ou não, a crítica acaba consequentemente relacionada a testes unitários também, é natural. É insano testes unitários em sistemas de informação. Muito custoso (imagina ter que testar até javascript) e chato (pela sensação de testar algo fake). Teste de verdade é o funcional.

      1. javaflex, como tudo na vida a resposta é DEPENDE!. Caso o sistema seja feito todo em js com node.js? Não testo meu código? Testa é necessário. O que nosso Mateus Queiroz Correia é bem coerente e concordo com ele. TDD só é mais uma das formas de garantir qualidade do código.

      2. @Bruno dos Santos Almeida, testa sim, como sempre foram testados os sistema, de forma funcional , só que agora de maneira automatizada com Selenium por exemplo. Ou seja, teste REAL, e não testes fakes como o unitário. Infelizmente as pessoas caem em doutrinas de igrejas de TI.

  27. Seus motivos foram superficiais, TDD não é caro no meu ponto de vista uma vez que todo bom desenvolvedor deve testar seus códigos. Testar antes ou depois é muito diferente? Levando a premissa que todo código deve ser testado, seja antes ou depois, qual a desvantagem de escrever o código antes ou depois? Testar os meios é mais difícil que o resultado final? Como disse um a amigo ai em cima antes de aplicar TDD devemos seguir os princípios SOLID. Uma vez que testados todas as partes em separado a chance do todo funcionar de forma correta é muito grande, sem contar que achar os gaps no fluxo da programação se torna uma tarefa menos complicada. Concordo que é chato ficar atualizando teste toda vez que a aplicação sofre uma alteração. Porém todas vez que uma nova funcionalidade é incluída ou uma já existente sofre alteração não temos que alterar a documentação? Teste acabam se tornando uma documentação em forma de código para o desenvolvedor. O fato é que que temos que ter teste para a nossa aplicação TDD só é mais uma das formas de se fazer. Para alguns vai funcionar, para outros não. As situações que o @dhh usou para exemplificar seus pontos de vistas foram bem convenientes com a idéia e não discordo que para coisas simples é meio inviável. Porem o ganho que o TDD trás para projetos que mais complicados são maiores, mesmo que indiretamente, do os motivos por você apresentados.

    1. Bruno, obrigado pelo seu comentário. Tudo que você está questionando está explicado no artigo. Tente ler de novo buscando as respostas ao que você questiona.

      Talvez você tenha dificuldade entende o que significa “caro” no contexto de desenvolvimento de projetos, se você nunca foi o cliente. Nesse caso, se um dia você tiver que contratar alguém para desenvolver e tiver o orçamento e tempo limitado (sempre é limitado) e vir onde o desenvolvedor gasta mais tempo e esforço, você vai se questionar, será que realmente vale a pena custo adicional de forçar o uso de TDD?

      A verdade é que muitos desenvolvedores só focados na parte técnica, não enxergam bem a parte dos custos reais dos projetos para os clientes, porque enquanto estão desenvolvendo nem sentem o tempo passado, mas o tempo passa e custa dinheiro para o cliente e você não vai querer que ele deixe de pagar.

leia mais
Este projeto é mantido e patrocinado pelas empresas: