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

S2

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

Acho que o TDD assim como outras práticas surgiram para resolver problemas, porém ao longo dos anos o programador foi limitado a posição de escrever código e a maioria ficou bem com isso.

Acho que um programador resolve um problema, mas nós fomos ensinados a pensar no problema apenas como um codigo e a solução como uma linguagem.

É fácil perceber isso, quando olhamos projetos aqui mesmo do tabnews e Plenos e Sêniors, não se dão ao trabalho nem de criar uma branch no github, fazem tudo na main, quando vemos diversos cursos ensinando linguagens que ninguém usa, mas nenhum ensinando sobre planejamento ou teste.

Acredito que o problema não é o TDD, o problema é o fato que a base dos programadores é baseada tanto em framework e linguagem, que o básico de testes muitos não sabe, que em vez de planejar, já abre o vscode e sai codando o que vem a cabeça.

Essa é apenas minha forma de vê as coisas, a IA chega escrevendo código mais rápido doque qualquer programador é capaz, mas a questão segue sendo: qual ia é melhor e não o que eu preciso estudar para ser um desenvolvedor melhor.

TDD na prática não é usado, pois o tempo para desenvolver o projeto é curto, como falei: o dev não aprende nem a planejar, então os prazos sempre ficam apertados e código vai para teste em produção e depois a gente corrige.

Não vou mentir, assim como cleancode, isso é aquela prática que na teoria é boa, mas no dia a dia com prazos limitados e zero noção de entrega, você deixa de lado, porque o cliente quer saber se funciona, se voce está num projeto com uma equipe bem estruturada e tudo planejado, fica fácil aplicar certas coisas e perceber que não e nada demais, porém na maior parte do tempo, voce está em projetos que ninguém tem noção do tempo gasto para nada e o resultado é o que já sabemos: coloca em prod e quando o cliente reclamar a gente ajeita.

Sempre que possível aprenda a teoria das coisas e aplique em pequenos projetos de final de semana, independente doque for, esse codigo vai para o lixo, mas você aos poucos está aplicando aquela teoria que você leu, mesmo que não precise disse agora, em algum momento pode surgi a oportunidade de você usar e muito desses conhecimentos se conectam com outros, nada vai realmente ser jogado fora, além de algumas linhas de código.

Livros seguem sendo ainda uma excelente fonte de consulta, não precisa ser escravo deles, pegue algum, leia, veja um vídeo, a teoria vai fazer sentido mesmo que em diversos vídeos o programador fale abobrinha as vezes.

Meus 2 cents,

Sobre TDD o @LucasMontano publicou um video hoje (seg, 20/abr) comentando um tweet do "Uncle Bob" sobre o assunto:

• o que vem depois da AI escrevendo código? (Uncle Bob)

Uma coisa tenho de reconhecer: se vamos delegar mais codigo para a IA (com seus volumes insanos), estruturas como PRD, SDD e TDD acabam sendo urgentes.

E talvez esse seja um elemento que nao gostamos de admitir: ainda vemos estes tipo de estrutura (como TDD) basicamente do ponto de vista humano e isto esta em transformacao, e nao importa que a IA/LLM ainda gere codigo lixo - em algum momento do tempo isso vai reflexionar, independente se daqui 2 meses, 6 meses ou 1 ano - e precisamos estar preparados para lidar com isso.

Talvez em breve acabemos criando outros tipo de estruturas, afinal tudo que temos foi criado/desenvolvido pensando em volume e velocidade humanos - para esta nova era de codificacao assistida por IA eh necessario repensar este ponto (e rapido).

Post devidamente favoritado via extensão TABNEWS FAVORITOS

Saude e Sucesso !

eu comecei a fazer depois que comecei a usar ia pra codar, porque é muito custoso pra fazer na mão mas com ia facilita muito, e nem todos os casos eu faço.