Toda pesquisa de "melhores práticas" de engenharia de software inclui TDD Por... · maniero

Em resposta a TDD na prática: quem realmente pratica no dia a dia?

Toda pesquisa de "melhores práticas" de engenharia de software inclui TDD

Por isso o primeiro vídeo do meu canal vai se chamar "A péssima prática de seguir boas práticas".

Todo dev experiente diz que TDD é importante

Nem todo. Inclusive quem cria linguagem de programação não costuma usar TDD, por que será? É o software que mais se beneficiaria disso.

Força você a pensar na interface antes da implementação. Isso melhora o design. Testes escritos depois tendem a testar implementação, não comportamento.

Se o programador é ruim o TDD não vai salvá-lo. Se ele é bom o TDD pode não ajudar muito.

Feedback imediato. Você sabe na hora se quebrou algo.

Só se souber fazer bem, o que é raro.

Documentação executável. Testes bem escritos descrevem o que o sistema faz melhor do que qualquer README.

Isso nunca foi verdade e todos os projetos documentam de outras formas porque TDD não foi feito para ensinar um humano como usar aquilo.

Velocidade inicial. Na fase exploratória de uma feature, eu não sei ainda qual é a interface certa. Escrever teste antes de saber o que está testando gera retrabalho.

Isso.

Tipos de código. TDD funciona bem para lógica de negócio. Para componentes visuais, integrações com APIs externas, scripts de migração: a aplicação mecânica de TDD gera testes frágeis.

Verdade.

Custo de manutenção. Testes mal escritos são piores do que não ter teste. E TDD praticado mal gera muitos testes mal escritos.

Exatamente.

Alguém aqui pratica TDD de forma consistente? Em que contexto funciona para vocês?

Pra você ver como é fácil fazer o TDD errado: o que uma resposta dada por uma pessoa aleatória na internet vai ajudar alguém programar melhor? Quando não há entendimento exato do que vai fazer, TDD não pode ser feito. Quando não se sabe o que pode ser respondido ou não, não adianta perguntar.

De maneira alguma estou dizendo que TDD não presta e nunca deva ser usado.

Pesquise sobre SDD. Eu ainda estou avaliando a utilidade. Eu não glorifico nada, eu não jogo nada no lixo até ter informações reais sobre algi. Não posso adotar ou afastar algo porque outras pessoas disseram que é bom ou ruim.

Falei muito sobre: https://www.google.com/search?q=maniero+tdd

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

obrenoalvim

15 horas atrás

O ponto sobre criadores de linguagem é forte, difícil argumentar contra. Acho que o problema com TDD é exatamente o que você descreveu: vira ritual sem entendimento. A maioria aprende o como sem nunca entender o quando e o por que. Vou pesquisar SDD, o nome não me era familiar. Qual você diria ser a diferença fundamental entre os dois?

maniero

Autor

14 horas atrás

Não sei ainda :D

SDD é uma abstração de maior nível, você documenta sem codificar, não é intenção dele fazer o que as pessoas acham que o TDD faz, mas ele não faz.

Não sei se é uma boa solução e sei que ele não elimina a necessidade de TDD se o projeto tem como requisito interno fazer os testes, mas pode ajudar na decisão de não fazer TDD.

Eu demoro para tomar uma decisão, porque ao contrário da maioria, eu só adoto algo depois de ter certeza que vai ajudar.

obrenoalvim

11 horas atrás

Faz sentido SDD ser uma camada acima: se a especificação já deixa claro o comportamento esperado, parte da necessidade do TDD como ferramenta de design de interface some. O problema é que a maioria dos projetos não tem especificação boa o suficiente pra isso funcionar de verdade.

O que me interessa no seu ponto é justamente essa distinção entre TDD como ferramenta de design versus TDD como ferramenta de verificação. O primeiro exige mudança de mindset real. O segundo é mais fácil de justificar, mas entrega menos valor.

Você já viu algum projeto em produção onde SDD eliminou de fato a necessidade de testes unitários, ou ainda é teoria a ser validada?