Elemar DEV

Tecnologia e desenvolvimento

Notas de leitura – The Clean Coder – Sobre TDD

Olá. Tudo certo?

Ainda estou lendo o livro “The Clean Coder“. Continuo compartilhando minhas impressões sobre alguns trechos.

Questão de profissionalismo

Vejamos o que o “Uncle” Bob tem a dizer sobre TDD.

How can you consider yourself to be a professional if you don’t know that all your code works? How can you know all your code works if you don’t test it every time you make a change? How can you test every time you make a change if you don’t have automated unit tests with very high coverage? How can you get automated unit tests with very high coverage without practicing TDD?

Contundente, não acha? Infelizmente, é lógico também.

The upshot of all this is that TDD is the professional option. It is a discipline that enhaces certainty, courage, defect reduction, documentation, and design. With all that going for it, it could be considered unprofessional not to use it.

As três leis do TDD

Uncle Bob fala sobre as três leis do TDD, feito da forma certa

  1. You are not allowed to write any production code until you have first written a failing unit test.
  2. You are not allowed to write more of a unit test than is sufficient to fail – and not compiling is failing.
  3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

 

Dramático e extremado. Confesso que, na prática, considero essa linha de desenvolvimento cara demais. Mais que isso, considero-a quase impraticável. Entretanto, reconheço, com certa vergonha, que é exatamente meu código não testado que costuma falhar na produção.

O que TDD não é?

For all its good points, TDD is not a religion or a magic formula. Following the three laws does not guarantee any of these benefits. You can still write bad code even if you write your tests first. Indeed, you can write bad tests.

By the same token, there are times when following the three laws is simply impratical or inappropriate. These situations are rare, but they exist. No professional developer should ever follow a discipline when that discipline does not harm than good.

Eis aqui uma margem perigosa para interpretações. Deveria, eu, ficar tranquilo tranquilo e assumir que minhas “quebras” são resultado de situações onde TDD deveria ser posto de lado?

Você está lendo esse livro? Que tal colaborar com suas impressões também?

 

10 comentários em “Notas de leitura – The Clean Coder – Sobre TDD

  1. Leandro
    23/04/2013

    Well, não li o livro. Mas acho que se uma lei prevê exceções, ela deve listar as exceções também. Ou teríamos “Esta é a lei; só que não é” :D

    Talvez fosse legal falar de “práticas” em vez de leis, e evoluir muito o assunto descrevendo os momentos onde elas se aplicam e onde não se aplicam.

    “Deveria, eu, ficar tranquilo e assumir que minhas “quebras” são resultado de situações onde TDD deveria ser posto de lado?”

    Resposta: eu posso ficar tranquilo se eu escrever testes que também detectem a quebra que foi detectada em produção, ainda antes de corrigir a quebra! Por mais que escrever este teste continue parecendo caro, ficou provado que não era tão caro, e será mais barato que a mesma quebra acontecendo de novo.

    “These situations are rare”; também posso ficar tranquilo se no meu dia-a-dia essas situações forem realmente raras. Eu me sinto desconfortável toda vez que não consigo aplicar TDD e acho que esse sentimento é útil.

  2. moreirayokoyama
    23/04/2013

    Eu odeio ser chato (mentira, às vezes adoro), mas eu acho que dizer que é caro seguir essas 3 “leis” é um exagêro. Não é assim tão custoso (na grande maioria das vezes – e por “grande maioria” eu quero dizer quase todas as vezes, somente abrindo espaço para raras exceções, que inclusive o próprio texto do uncle Bob cita) criar um teste que me dê uma evidência concreta de que eu sei o que estou querendo fazer e que me convença de que meu propósito foi alcançado.

    • elemarjr
      23/04/2013

      Daniel,

      Há quase um consenso de que manter 100% de cobertura é muito caro. Além disso, raramente agrega valor de verdade.

      Você discorda disso? Você mantem 100% de cobertura?

  3. moreirayokoyama
    23/04/2013

    Eu não me referia a 100% de cobertura, e sim a respeito de criar um teste para cada alteração que eu faço no meu código.
    Isso me ajuda a raciocinar, provar pra mim mesmo que eu sei o que eu quero (a ponto de escrever um teste) e me ajuda a obter evidência de que o que eu queria está funcionando como eu queria.
    Isso normalmente deixa a cobertura de testes bem alta (>90% normalmente).
    Mas não é pela cobertura.
    Entretanto, a empresa onde estou agora resolveu adotar a medida chata de exigir 100% de cobertura (exclusões da cobertura precisam ser justificados e serão verificados). Eu também acho exagêro, pra isto tenho que inventar testes que simulam situações muito improváveis. Mas seria justo eu dizer (apesar de concordar que não é necessário) que isto não me toma tanto tempo assim.
    Eu não concordo que seja muito caro. Eu só acho que pode haver algum desperdício, sim… sem contar o fato de que forçar 100% de cobertura é se apoiar em uma medida muito subjetiva (já mencionei isto ao meu gerente).
    Sim: Estou sendo forçado a manter 100% de cobertura. Mas não acho que isso seja necessário, e não era disto que eu estava falando. Eu só disse que não acho caro criar um teste para a alteração que vc pretende fazer no código.

    • elemarjr
      23/04/2013

      Concorda que seguir as leis implica, obrigatoriamente, em 100% de cobertura?

  4. Robson Castilho
    23/04/2013

    Apesar de não estar lendo este livro, gosto bastante dos livros e artigos do Uncle Bob. São contundentes e me fazem querer sempre melhorar como profissional.

    Quanto às leis, não pratico 100% do tempo. Mas estou procurando me policiar mais para alguns métodos que acho “mais bobos” e começar pelos testes mesmo assim.

    Não sou obcecado por 100% de cobertura. O importante é ter uma boa base de código “seguro” para ser alterado.

    @Leandro,
    Ele lista as exceções sim. Não sei se lista nesse livro mas aqui está:

    http://blog.8thlight.com/uncle-bob/2013/03/06/ThePragmaticsOfTDD.html

    O Mark Seeman rebateu o post acima no blog dele:

    http://blog.ploeh.dk/2013/03/11/listen-to-trivial-tests/

    []s

  5. ericlemes
    23/04/2013

    Elemar,

    Eu tbém tô me rendendo à linha de pensamento dele. Tenho começado a perceber diversas barbeiragens que tenho feito. E tenho percebido que estou usando meu pensamento “orientado a negócio” como desculpa pra entregar software ruim.

    Quanto mais estou aprofundando meu conhecimento em TDD estou chegando à conclusão que a curva de produtividade de um projeto “cascata”, sem práticas de desenvolvimento como TDD é logarítmica. Você começa se achando todo produtivo, após colocar o primeiro pedaço de código em produção, sua produtividade despenca e assim vai até o projeto ruir.

    No TDD é menor no começo, mas é constante. Vc consegue dar cadência no projeto.

    O culpado disso é o Maurício Aniche. Nâo sei se eu agradeço ele, ou brigo com ele.

    Abraço,

    Eric

  6. Li esse livro há alguns meses. Muito bom.
    Recentemente ele (Uncle Bob) falou sobre esse ponto de vista dogmático em relação à prática de TDD, pelo qual ele é sempre criticado.
    Gostei bastante da resposta dele.
    Escrevi um artigo fazendo uma transcrição e comentando a respeito à época. http://www.rafaelromao.com/2013/03/pragmatismo-e-tdd.html

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado às 23/04/2013 por em Post e marcado , .

Estatísticas

  • 674,175 hits
%d blogueiros gostam disto: