Recentemente, dei uma palestra sobre depuração para a London Java Community. Durante a parte de perguntas e respostas da palestra, alguém me perguntou sobre minha abordagem para Test Driven Development. No passado, eu olhava para essa prática de uma forma mais positiva. Escrever muitos testes. Como aquilo pode ser mau?  Mas com o passar do tempo, vejo isso sob uma luz diferente.  Eu o vejo como uma ferramenta muito limitada que tem casos de uso muito específicos. Não se encaixa no tipo de projetos que construo e muitas vezes atrapalha os processos fluidos que deveria promover. Mas vamos voltar atrás por um segundo. Gostei muito   que separa os tipos e problemas em TDD. Mas vamos simplificar um pouco, vamos esclarecer que todo PR deve ter uma boa cobertura. Isso não é TDD. É apenas uma boa programação. desse post  TDD é mais do que isso. Nela, precisamos definir as restrições e então resolver o problema. Essa abordagem é superior a resolver o problema e, em seguida, verificar se as restrições estão corretas? Essa é a premissa principal do TDD versus apenas escrever uma boa cobertura de teste.  O bom  TDD é uma abordagem interessante. É especialmente útil ao trabalhar com linguagens de tipo flexível. Nessas situações, o TDD é maravilhoso, pois preenche o papel de um compilador e linter estrito.  Há outros casos em que faz sentido. Quando estamos construindo um sistema que tem entradas e saídas bem definidas. Já me deparei com muitos desses casos ao criar cursos e materiais. Ao trabalhar com dados do mundo real, isso às vezes acontece quando temos um middleware que processa dados e os gera em um formato predefinido.  A ideia é construir a equação com as variáveis ocultas no meio. Em seguida, a codificação torna-se o preenchimento da equação. É muito conveniente em casos como esse. A codificação torna-se o preenchimento dos espaços em branco.  O mal  “Desenvolvimento Orientado a Testes   Contabilidade de Entrada Dupla. Mesma disciplina. Mesmo raciocínio. Mesmo resultado.” – Tio Bob Martin É  Eu diria que o teste é um pouco como a contabilidade de partidas dobradas. Sim. Deveríamos ter testes. A questão é devemos construir nosso código com base em nossos testes ou vice-versa? Aqui a resposta não é tão simples.  Se tivermos um sistema pré-existente com testes, então o TDD faz todo o sentido do mundo. Mas testando um sistema que ainda não foi construído. Há alguns casos em que faz sentido, mas não com tanta frequência quanto se poderia pensar.  A grande reivindicação do TDD é “seu design”. Os testes são efetivamente o design do sistema e, em seguida, implementamos esse design. O problema com isso é que também não podemos depurar um design. No passado, trabalhei em um projeto para uma grande empresa japonesa. Esta empresa tinha um dos maiores e mais detalhados conjuntos de livros de design de anexos. Com base nessas especificações de projeto, a empresa construiu milhares de testes. Deveríamos passar por uma grande quantidade de testes com nosso sistema. Observe que a maioria nem era automática.  Os testes tinham bugs. Houve muitas implementações concorrentes, mas nenhuma delas encontrou os bugs nos testes. Por quê? Todos eles usaram o mesmo código-fonte de implementação de referência. Fomos a primeira equipe a pular isso e fazer uma implementação de sala limpa. Isso perpetuou esses bugs no código, alguns deles eram sérios bugs de desempenho que afetaram todas as versões anteriores.  Mas o verdadeiro problema era o progresso lento. A empresa não poderia avançar rapidamente. Os proponentes do TDD serão rápidos em comentar que um projeto TDD é mais fácil de refatorar, pois os testes nos dão uma garantia de que não teremos regressões. Mas isso se aplica a projetos com testes realizados após o fato.  O pior  O TDD se concentra fortemente em testes de unidade rápidos. É impraticável executar testes de integração lentos ou testes de execução longa que podem ser executados durante a noite em um sistema TDD. Como você verifica a escala e a integração em um sistema principal?  Em um mundo ideal, tudo se encaixará como legos. Eu não vivo em um mundo assim, os testes de integração falham muito. Essas são as piores falhas com os bugs mais difíceis de rastrear. Eu prefiro ter uma falha nos testes de unidade, é por isso que os tenho. Eles são fáceis de corrigir. Mas mesmo com cobertura perfeita, eles não testam a interconexão adequadamente. Precisamos de testes de integração e eles encontram os bugs mais terríveis.  Como resultado, o TDD enfatiza demais os testes de unidade “bom ter” sobre os testes de integração essenciais. Sim, você deve ter os dois. Mas devo fazer os testes de integração. Esses não se encaixam tão bem no processo TDD.  Teste orientado para a direita  Escrevo testando da maneira que escolho caso a caso. Se eu tiver um caso em que testar com antecedência é natural, usarei isso. Mas, na maioria dos casos, escrever o código primeiro parece mais natural para mim. Revisar os números de cobertura é muito útil ao escrever testes e isso é algo que faço após o fato.  Como mencionei antes, só verifico a cobertura para testes de integração. Gosto de testes de unidade e de monitorar a cobertura lá, pois também quero uma boa cobertura. Mas, para qualidade, apenas os testes de integração importam. Um PR precisa de testes de unidade, não me importo se os escrevemos antes da implementação. Devemos julgar os resultados.  Automação Ruim  Quando a   estava construindo suas fábricas do Modelo 3, ela entrou no inferno da produção. A fonte dos problemas foi a tentativa de automatizar tudo. O   se aplica perfeitamente à automação. Algumas coisas são muito resistentes à automação e tornam todo o processo muito pior. Tesla Princípio de Pareto  Um ponto em que isso realmente falha é no teste de interface do usuário. Soluções como Selenium etc. fizeram grandes progressos nos testes de front-ends da web. Ainda assim, a complexidade é tremenda e os testes são muito frágeis. Acabamos com testes difíceis de manter. Pior, achamos a interface do usuário mais difícil de refatorar porque não queremos reescrever os testes.  Provavelmente podemos cruzar 80% da funcionalidade testada, mas há um ponto de retornos decrescentes para automação. Nesses ambientes, o TDD é problemático. A funcionalidade é fácil, mas construir os testes torna-se insustentável.  Finalmente  Não sou contra TDD mas não recomendo e efetivamente não uso. Quando faz sentido começar com um teste, posso fazer isso, mas isso não é realmente TDD. Eu julgo o código com base nos resultados. O TDD pode fornecer ótimos resultados, mas geralmente enfatiza demais os testes de unidade. Os testes de integração são mais importantes para a qualidade a longo prazo.  A automação é ótima. Até que pare. Há um ponto em que os testes automatizados fazem pouco sentido. Isso nos pouparia muito tempo e esforço para aceitar isso e focar nossos esforços em uma direção produtiva.  Isso é do meu viés como desenvolvedor Java que gosta de linguagens estritas e seguras. Linguagens como JavaScript e Python podem se beneficiar de um volume maior de testes devido à sua flexibilidade. Portanto, o TDD faz mais sentido nesses ambientes.  Em resumo, o teste é bom. Porém, TDD não faz testes melhores. É uma abordagem interessante se funcionar para você. Em alguns casos é enorme. Mas a ideia de que o TDD é essencial ou mesmo que irá melhorar significativamente o código resultante não faz sentido.  Também publicado  aqui.

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Por que não acho que o TDD seja essencial

Por que não acho que o TDD seja essencial

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps