Técnica TDD (Test Driven Development) você já esta aplicando em seu projeto? Puxão de orelha no final.

Uma coisa q gostaria de adicionar para qm ler, q TDD é um estilo de codificação e não testes de unidade em si.

Um software pode ter testes sem usar TDD. É a melhor forma? Não sei, depende de como a pessoa tem a capacitação de criar testes e não do estilo q ele cria o teste.

Vou explicar com base na minha opinião, pode discordar caso não ache válido, mas diga o pq.

Pelo TDD vc começa pelo teste. Então cria a casca do q quer, coloca os dados de entrada q quer q aconteça, falha, desenvolve o código, dá certo, passa pro próximo teste e assim vai.
Se não usar TDD, ou seja, vc inicia pelo código antes (o q todo mundo normalmente faz), depois cria os testes com base no q já está pronto.

Ai vem 2 pontos de cada um.

Nem sempre no TDD sabemos como deve ficar, muito menos sabemos 100% os dados de entrada. Isso querendo ou não pode mais atrapalhar do q ajudar.

No modo não TDD, a gente cria o código, mas sempre existe o problema de termos criados condições q nunca iremos saber se realmente acontece, pois nossa mente está preparada apenas para enxergar o caso ótimo, então pelo menos isso a gente testa, mas os casos de falhas é o q fica capenga e nem sempre conseguimos ter 100% de precisão nisso.

Mas até qndo usamos TDD pode acontecer problemas de falhas serem esquecidas.

Então eu cheguei numa conclusão q depende mto qndo usar um ou quando usar outro estilo de criação de testes.

O TDD eu crio para aqueles casos onde tenho mais certeza do q quero, como nos algoritmos incluso na caixa preta, por exemplo, validação do CPF, conversão de datas para uma string formatada, algumas regras de negócios bem estabelecidas como boletos, etc. São normalmente coisas mais básicas, q tem um resultado pré definidos q não pode mudar.

Agora lógicas q usamos nas páginas, regras de negócios mais dinamicos, e2e, etc eu faço da forma código antes, testes depois.

Ai vcs podem me dizer, o jeito q utilizo esses 2 estilos é a melhor forma de fazer? Não sei, pois cada um programa de um jeito. Estilo de programar tem mto mais haver com a maneira q a pessoa lida, então não tem como saber se é o melhor jeito, pois a qualidade do teste está mto mais relacionado a como o teste foi codificado e o q ele codificou, e não qual maneira ele fez o teste.

A única certeza q tenho é deixar seu código de produção sem testes só demonstra a incapacidade do dev de pensar a longo prazo, pois ele é algo chato de se criar, mas é uma proteção contra instabilidades e má manutenções futuras. Portanto coloque testes, seja do modo TDD ou seja do modo não TDD.

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

Eu falei bastante a respeito em diversos lugares. Geral eu desglorifico o TDD, então algumas pessoas não gostam. Não digo que ele é um lixo e não deve ser usado, mas que ele não é bala de prata e boa parte das pessoas usam errado e não conseguem benefícios que compensem o custo.

Eu cito muito o exemplo de linguagens de programação que são exemplos perfeitos onde o TDD se encaixaria bem, e você não vê ele sendo aplicado na construção dos compiladores. Em geral são programadores muito bons que sabem avaliar o peso que o TDD tem no projeto, seja na parte positiva quanto negativa.

Infelizmente a maioria adota por modinha e não porque sua enorme experiência indica que será mais positivo que negativo.

TDD, assim como muitas ferramentas, não podem ser endeusadas e só olhadas de um lado (positivo). Por isso minha primeira postagem no Youtube e Substack será uma versão da minha palestra "A Péssima Prática de Seguir Boas Práticas". E ela será importante para todo o resto que eu for públicas, incluindo as boas práticas.

S2

---

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