Executando verificação de segurança...
1

TDD: Andar de Skate no Mundo da Programação 🛹💻

Quando comecei a programar, trabalhava sem utilizar testes automatizados, apenas os manuais (e quem nunca?). Com o tempo, percebi que precisava melhorar essa habilidade, então decidi dar o próximo passo: adotar o uso de testes. E, sem querer, acabei me deparando com o TDD.

Pra mim, TDD é como aprender a andar de skate. No começo, a gente não sabe muito bem o que fazer, é só tentativa e erro. Porém, à medida que vamos praticando e ganhando confiança, o caminho começa a ficar mais claro. Eu também comecei a testar de forma um pouco desordenada, assim como quem tenta aprender o "ollie" pela primeira vez. Pesquisar na internet e trocar ideias com outros programadores foi essencial para me sentir mais seguro nesse processo.

A maior vantagem de usar TDD é que, ao alterar um trecho de código, tenho a garantia de que não quebrei nada que estava funcionando. É como traçar o percurso de um skate park antes de descer por ele. Com o TDD, planejo cada "movimento", garantindo que meu código siga o trajeto certo.

TDDSkate

  1. Escreva um teste que falhe (Aprender a manobra)
    Assim como quando você tenta uma manobra no skate e erra no início, no TDD, você escreve um teste que falha porque ainda não implementou o código.

  2. Faça o código funcionar (Executar a manobra)
    Com a prática, você começa a acertar a manobra. No TDD, você escreve o código necessário para que o teste passe.

  3. Refatore (Aperfeiçoar a manobra)
    Depois de aprender a manobra, você a aperfeiçoa. No TDD, você refatora o código para torná-lo mais limpo e eficiente, sem perder a funcionalidade.

Claro que, assim como no skate, existem momentos em que é necessário "freestyle". Em projetos menores, por exemplo, não vejo a necessidade de testar todos os cenários possíveis, focando apenas no essencial.

TDD, assim como o skate, exige prática constante. E quanto mais você se dedica, mais confiante e habilidoso se torna, seja na programação ou nas manobras!

Carregando publicação patrocinada...
2

Sinto lhe informar, mas você não entendeu TDD ainda.

De fato, qualquer coisa que for aplicar precisa aprender completamente como fazer, porque se fizer errado tem pouco valor, eu tenho uma palestra chamada "Não faça teste". Onde eu mostro porque grande parte dos testes não deveriam ser feitos, e claro, o que fazer para melhorar nisso. Eu não dou receitas de bolo de como fazer testes, porque isso é ooposto que a pessoa deveria fazer. Eu vejo muito em Github testes que não tem serventia alguma e a falta de testes em coisas fundamentais. A pessoa só faz burocraticamente.

Primeiro, ter confiança em alterar algo no código e não quebrar nada é fazendo testes, especialmente os de unidade (que muita gente chama de unitário, mas está errado, e mostra que a pessoa aprendeu errado). Não precisa de TDD para isto. Inclusive, pára pra pensar, o TDD prega fazer o teste antes de escrever o código, vai quebrar o que? Ah, ok, é para dar vermelho e depois verde, mas esse não é o objetivo. Então está longe dessa ser a maior vantagem do TDD, ou até mesmo que podemos dizer que é uma vatagem do TDD porque quem entrega essa vantagem é outra técnica, que por acaso é adotada no TDD.

Percebe que entender corretamente o problema é fundamental para fazer testes bons? E mais ainda se for aplicar o TDD porque tudo será regido de acordo com esses testes, então se fizer o TDD errado, todo o resto ficará capenga ou errado, passando no teste. Entender problemas corretamente e achar boas soluções para eles são as características fundamentais de todo bom desenvolvedor, o resto é só ferramenta. Por isso eu semrpe digo que entender de verdade a matemática e ser razoável em comunicação e expressão são a base de todo programador. Inclusive para ter um olhar mais questionador e não aplicar coisas onde não deve, só para seguir a modinha.

A função principal do TDD não é fazer testes, esses são usados como ferramenta. A função do TDD é planejar melhor o que vai fazer e documentar antes de tudo. Por isso precisa ser muito bem feito ou é muito melhor nem fazer.

Um dos grandes problemas que vejo no aprendizado do TDD é justamente a simplificação e fazer parecer que ele deve ser aprendido por si só. Tem que aprender resolver problemas, dominar os conceitos a computação, o TDD, se for realmente útil em um projeto, e tem que estar apto a determinar isso com destreza, deve ser uma consequência natural e competente porque já sabe o que vem antes.

TDD deveria ser das últimas coisas que a pessoa aprende e deve ser fácil porque ele em si não tem nada demais, o que precisa aprender antes é criar os requisitos de forma quase perfeita, e eu diria que ninguém consegue fazer isso o tempo todo, eu não consigo com mais de 40 anos de experiência, os melhores engenheiros, os com cargos distintos em big techs, falham nisso em várias situações. O problema é falhar muito. E deve entender tudo de computação para saber o que testar, e só depois de muita experiência você está apto a fazer TDD. Pode fazer sob estrita supervisão, para gerar até improdutividade no time para treinar você que vai começar fazer, ou seja, você vai fazer e outro experiente e que realmente saiba fazer os testes usando TDD vai corrigir tudo para você aprender onde errou. Quase ninguém faz isso, por isso é trágico o que vejo por aí.

A última coisa que eu acho que não entendeu é que ou testa tudo ou não testa, testar mais ou menos é o pior cenário. Claro que você pode escolher testar um componente crítico muito bem e não testar outros componentes, mas não pode testar algo pela metade porque o projeto é mais simples. Geralmente projetos simples, que vão ter pouca manutenção, talvez dure pouco, não é tão necessário fazer testes, mas tem que avaliar caso a caso, pode estar fazendo algo que tenha potencial de destruir dados, mesmo com meia dúzia de linhas.

Eu já falei mais sobre TDD diversas vezes e vou consolidar tudo em uma série de artigos no meu blog e canal que logo se iniciará.

Veja mais:

S2


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

  • uma das críticas que faço ao modelo do Tabnews é que se perde muito conteúdo relevante.
1

Obrigado pelo comentário! Concordo que TDD exige um nível de compreensão muito maior do que simplesmente escrever testes antes do código, e que sua real aplicação demanda experiência para ser feita corretamente.

Ainda estou no início da minha jornada com Teste e TDD, e esse post foi mais um registro do meu aprendizado do que uma tentativa de ensinar ou afirmar verdades absolutas. Acabei não deixando isso tão explícito na publicação, mas meu objetivo aqui é justamente compartilhar a experiência e aprender com a comunidade.

Achei interessante seu ponto sobre a importância de primeiro dominar a resolução de problemas e os fundamentos da computação antes de adotar TDD de forma produtiva. Concordo que aplicar testes sem um entendimento sólido pode se tornar apenas um processo burocrático, sem real benefício para o código. Ao mesmo tempo, é preciso começar de alguma forma, pois só assim é possível evoluir e aprimorar a experiência. No início, meus testes cobriam muitos aspectos que hoje percebo não fazerem tanto sentido, mas esse processo foi essencial para meu aprendizado. Hoje, vejo o TDD como uma ferramenta que ajuda a planejar melhor o que quero como resultado.

Agradeço pelo feedback e pelas reflexões! Com certeza vou levar esses pontos em consideração na minha evolução com testes e TDD.

1
1

Não está, mas vou tranformar isso em texto e vídeo, só não posso prometer quando porque tem uma fila enorme de outras coisas que são mais prioridade. Apesar de parecer simples, fazer teste é algo que demanda muito conheicimento e experiência, não deve ser visto muito cedo, porque cai no que eu semrpe falo, você vai treinar o erro.