Experiência negativa no TDD [fechada]

95

Qual é o lado negativo da sua experiência no TDD? Você acha os passos do bebê (a solução mais simples para tornar o teste verde) irritante e inútil? Você acha que a manutenção de testes sem valor (quando o teste tem sentido inicialmente, mas na implementação final verifica a mesma lógica dos outros testes) é essencial? etc.

As perguntas acima são sobre coisas com as quais me sinto desconfortável durante minha experiência no TDD. Então, estou interessado em saber se outros desenvolvedores têm sentimentos semelhantes e o que eles pensam deles.

Ficaria grato pelos links para os artigos que descrevem os lados negativos do TDD (o Google é preenchido por artigos positivos e muitas vezes fanáticos).

Idsa
fonte
10
Meu palpite é que você não ouvirá muitas respostas honestas sobre as experiências negativas das pessoas, porque o TDD ainda está em um estado de "adotantes iniciais" e a maioria das pessoas interessadas e comprometidas o suficiente para experimentá-las não é objetiva o suficiente para avaliá-lo por seus méritos relativos. Geralmente, leva vários anos para que a indústria realmente estabeleça os efeitos a longo prazo de novos processos e técnicas, e mesmo assim é difícil obter respostas diretas devido à falta de controles. Boa pergunta, no entanto, e boa sorte em obter respostas úteis!
Aaronaught
20
Você está tendo problemas para encontrar negatividade na internet ?!
Eric Wilson
4
@ Job (e possivelmente outro): não esqueça que ele perguntou sobre TDD, não sobre testes de unidade. TDD! = Teste de unidade.
N1ckp
2
Estou tentado a responder a essa pergunta, mas não quero realmente começar, porque levará metade do meu dia.
Rei Miyasaka
2
Quando eu me pego gastando tempo suficiente em bugs, parece que eu poderia gastar menos tempo escrevendo testes para todas as coisas que escrevo antes de escrevê-las, não adotarei o TDD test-first-all-things-TDD. Em vez disso, vou envergonhar a cabeça e começar a procurar uma nova carreira. Não é sobre erros que você diz? Desenhar? Sim. É isso aí. É exatamente isso. E você não aprendeu nada sobre design robusto, dando a si mesmo uma rede de segurança e uma licença para continuar trabalhando estupidamente. Coloque o IDE de lado e tente ler seu código se quiser descobrir o problema real.
Erik Reppen

Respostas:

95

Como tudo o que vem sob o banner "Agile", o TDD é algo que soa bem na teoria, mas na prática não é tão claro o quão bom é (e também como a maioria das coisas "Agile", você é informado de que, se não o fizer, você está fazendo errado).

A definição de TDD não está gravada em pedra: caras como Kent Beck exigem que um teste não-compilador seja escrito antes de uma única linha de código e toda linha de código seja escrita para passar em um teste com falha. O design inicial é mínimo e tudo é impulsionadopelos testes. Simplesmente não funciona. Eu vi um grande aplicativo corporativo desenvolvido usando essa metodologia e espero que seja o pior código que vejo na minha carreira (não será muito distante; e isso apesar de ter alguns desenvolvedores talentosos trabalhando nisso). Pelo que vi, resulta em um grande número de testes mal pensados ​​que validam principalmente que ocorrem chamadas de função, que exceções são lançadas quando as variáveis ​​são nulas e a estrutura de zombaria recebe um treino completo (whoop-de-whoop); seu código de produção fica muito acoplado a esses testes e o sonho de refatoração constante e fácil não aparece - na verdade, as pessoas têm ainda menos probabilidade de corrigir códigos incorretos por causa de todos os testes que serão interrompidos.

Por outro lado, ouvi pessoas argumentarem que TDD significa projetar os testes antecipadamente em alto nível como parte da fase de planejamento - juntamente com o projeto arquitetônico. Esses testes podem mudar durante o desenvolvimento à medida que mais informações se tornam disponíveis, mas foram cuidadosamente considerados e oferecem um bom guia sobre o que o código realmente deve fazer. Para mim, isso faz todo o sentido.

user23157
fonte
7
+1 "projetar os testes antecipadamente em alto nível, como parte da fase de planejamento - juntamente com o projeto arquitetônico" Parece muito mais razoável para mim também.
Steven Jeuris
11
@Aaronaught Agile não significa nenhum planejamento, significa apenas dentro do prazo .
Adam Jaskiewicz
25
@ Adam Jaskiewicz: Eu amo a coisa "sem planejamento antecipado". Vamos lá, o planejamento é aberto por definição . Se você não planeja antecipadamente, mas durante o evento, você não está planejando; você está improvisando. ;-)
CesarGon 4/11
34
@ Adam - "As pessoas realmente saltam direto para a codificação no primeiro dia de uma iteração?" erm sim. Esse é o homem "ágil". No último lugar em que trabalhei (e fui demitido por não ser "Agile"), eles fizeram um ciclo de lançamento completo de três meses sem planejar uma única linha de código ou fazer uma única página de documentação. E sim, o código era terrível e o software era lento, desajeitado e com erros. No dia em que entrei, o gerente me disse com orgulho que eles eram "a loja mais ágil de Londres". Eles com certeza foram.
7
Pode adicionar outro problema: desde que passe no teste, ele deve ser bom. Não importa que o teste em si possa falhar e, assim, causar falsos negativos e / ou falsos positivos. E, é claro, exigir "100% de cobertura de teste" e tudo o que tem é, por definição, perfeito, causando testes inúteis que na verdade não testam nada, mas são escritos apenas para atingir essa cobertura de 100%, código que não é documentado porque o contador de cobertura conta comentários como código descoberto, etc. etc.
jwenting
67

Esta entrevista com Rich Hickey ( autor do Clojure ) contém o seguinte. Sinto-me 100% solidário:

A vida é curta e há apenas um número finito de horas em um dia. Então, temos que fazer escolhas sobre como gastamos nosso tempo. Se o gastamos escrevendo testes, é hora de não gastarmos fazendo outra coisa. Cada um de nós precisa avaliar a melhor forma de gastar nosso tempo para maximizar nossos resultados, tanto em quantidade quanto em qualidade. Se as pessoas pensam que gastar cinquenta por cento do tempo escrevendo testes maximiza seus resultados - tudo bem para eles. Tenho certeza de que isso não é verdade para mim - prefiro gastar esse tempo pensando no meu problema. Estou certo de que, para mim, isso produz melhores soluções, com menos defeitos, do que qualquer outro uso do meu tempo. Um design ruim com um conjunto de testes completo ainda é um design ruim.

Outra declaração semelhante de Donald Knuth na entrevista do livro Coders at Work , copiada e colada a partir daqui :

Seibel: Falando em trabalho prático, no meio de trabalhar em The Art of Computer Programming, você fez o que se transformou em uma pausa de dez anos para escrever o seu sistema de digitação TeX. Entendo que você escreveu a primeira versão do TeX completamente fora do computador.

Knuth: Quando escrevi o TeX originalmente em 1977 e 78, é claro que não tinha programação alfabetizada, mas tinha programação estruturada. Escrevi em um caderno grande à mão, a lápis. Seis meses depois, depois de concluir todo o projeto, comecei a digitar no computador. E fiz a depuração em março de 78, quando eu comecei a escrever o programa em outubro de 1977. O código para isso está nos arquivos de Stanford - está tudo a lápis - e, é claro, eu voltaria e mudaria uma sub-rotina enquanto aprendia o que deveria ser. Este era um sistema de primeira geração; portanto, várias arquiteturas diferentes eram possíveis e precisavam ser descartadas até que eu morasse com ele por um tempo e soubesse o que havia lá. E era um problema de galinha e ovo - você não podia digitar até ter fontes, mas não podia ter fontes até poder digitar. Mas a programação estruturada me deu a ideia de invariantes e saber fazer caixas pretas que eu pudesse entender. Então, eu tinha a confiança de que o código funcionaria quando eu finalmente o depurasse. Eu achava que economizaria muito tempo se esperasse seis meses antes de testar qualquer coisa. Eu tinha confiança suficiente de que o código estava aproximadamente correto.

Seibel: E a economia de tempo seria porque você não gastaria tempo construindo andaimes e stubs para testar código incompleto?

Knuth: Certo.

Joonas Pulakka
fonte
24
Eu acho que você tem que olhar para o tipo de trabalho que está fazendo. Knuth e Hickey estão falando sobre o design de novas aplicações (inovadoras). Se você observar onde o TDD é popular (ampla generalização excessiva), você perceberá que a maioria dos aplicativos escritos de maneira TDD já possui uma arquitetura conhecida.
precisa
4
Entendo o significado de Rich Hickey, mas gostaria de acrescentar: Minha experiência é que, ao escrever os testes, você precisa realmente pensar no seu design e pensar em como tornar seu código testável, o que, na minha experiência, resulta em melhor design.
Niklas H
3
Como o OP solicita experiências negativas com o TDD, nenhum dos seus exemplos parece relevante para essa questão, pois também não mostra um exemplo de TDD em ação.
Winston Ewert
5
@ Michael Borgwardt: É relativamente fácil adicionar testes a um bom design existente, para se livrar de bugs na implementação. Mas livrar-se de um design ruim geralmente significa uma reescrita completa. Portanto, o objetivo principal deve ser obter o design certo; a execução é mais fácil de corrigir posteriormente.
Joonas Pulakka
4
A maioria dos aplicativos de negócios não tem o benefício de ser escrita e / ou mantida por Donald Knuth. O tempo de vida de um aplicativo geralmente é MUITO mais longo que o desenvolvimento primário. Eu gostaria que as pessoas tivessem escrito mais testes antecipadamente no meu projeto atual. Agora a manutenção é como um campo minado de regressões infinitas.
Matt H
58

Minha experiência negativa com TDD foi minha primeira. O TDD me pareceu ótimo, eu fiz controle de qualidade por anos e ainda tinha os horrores frescos em minha mente. Eu queria esmagar todos os erros antes que ele se tornasse uma compilação. Infelizmente, o uso do TDD não garante que você escreva bons testes. De fato, minha predisposição inicial era escrever testes simples que gerassem código simples. Código realmente simples que continha poucas abstrações. Testes realmente simples que foram interligados com os internos da turma. E depois que você tiver alguns milhares de testes, você certamente não se sentirá mais rápido quando precisar alterar centenas deles para refatorar seu código e usar o conceito de domínio X muito importante.

A luz acendeu para mim - TDD não é uma habilidade de teste. É uma habilidade de design. Ele só pode levar você a um código bom, simples e viável, com prática e um conhecimento constante das instruções de design em que ele o leva. Se você estiver escrevendo testes para garantir a cobertura do código, criará testes frágeis. Se você estiver escrevendo testes para ajudá-lo a projetar suas abstrações, é apenas uma maneira mais rigorosa de escrever código de cima para baixo. Você vê o código da perspectiva do interlocutor primeiro, o que o incentiva a facilitar a vida dele, em vez de espelhar os componentes internos de uma classe para a borda externa.

Eu acho que o TDD é útil, mas não sou dogmático. Se esses "testes sem valor" estiverem dificultando a manutenção - exclua-os! Trato testes da mesma maneira que o resto do código. Se puder ser refatorado e tornar as coisas mais simples, faça-o!

Não o vi pessoalmente, mas ouvi dizer que alguns lugares rastreiam a cobertura do código e a contagem de testes. Portanto, se a coleta de métricas é um efeito colateral do TDD, também pude ver isso como negativo. Vou excluir com entusiasmo 1000 linhas de código e, se isso obsoleta 20 testes e diminui a minha cobertura de código%, tudo bem.

Steve Jackson
fonte
7
Você acertou em
cheio
4
"Eu não vi isso pessoalmente, mas ouvi dizer que alguns lugares rastreiam a cobertura de códigos e a contagem de testes". Vivi em um ambiente como esse e, de fato, nenhum código foi jogado fora, porque isso causaria uma falha no teste. Até que comecei a depurar os testes reais, e encontrei muitos deles com falhas tão sérias que forçaram o código a produzir resultados incorretos para que os testes passassem. Foi quando cunhei a pergunta: "quem está testando os testes", para o qual até agora nunca recebi uma resposta satisfatória da comunidade do TDD. Testes unitários para testes unitários, alguém?
jwenting
@jwenting - E essa anedota apoia bastante o argumento de Rei. Eu descobri que o aspecto de proteção de regressão do TDD é exagerado na prática, mesmo que seja uma idéia sólida em teoria. Os testes precisam ser mantidos no mesmo nível do código de produção para que funcione, e é um pouco natural tratar o código de não produção dessa maneira - eu vejo o mesmo "código apodrecido" com simuladores de hardware, geradores de código, etc o tempo todo.
101311 Steve Jackson
"Testes realmente simples que foram entrelaçados com os internos da turma" <- aí está o seu problema. Teste apenas para interfaces públicas. TDD! = UT
Steven A. Lowe
2
@ StevenA.Lowe - Eu sei disso agora, mas há 9 anos não era tão claro :) "TDD não é uma habilidade de testes"
Steve Jackson
41

Eu vou sair por aqui e declarar com honestidade brutal que é literalmente uma perda de tempo ritualística. (Na maioria das situações.)

Comprei um livro sobre testes de unidade que também discutia o TDD e, embora eu concorde com os benefícios da UT, depois de cem horas experimentando o TDD, desisti dele por uma infinidade de razões. Eu sou tipo de postagem cruzada aqui, mas TDD:

  1. Não é melhor documentação do que documentação real.
  2. Não captura bugs ou regressões .
  3. Realmente não faz meus projetos melhores do que acabam sendo se eu aplicar alguns conceitos funcionais de programação e composição .
  4. É o tempo que poderia ser melhor gasto fazendo revisões de código ou aprimorando a documentação e as especificações.
  5. Dá aos gerentes uma falsa sensação de segurança quando vêem uma lista de centenas de ícones verdes.
  6. Melhora a produtividade na implementação de algoritmos com mapeamentos de entrada e saída limitados.
  7. É desajeitado porque você pode saber o que está fazendo como resultado do TDD, mas não está entendendo por que funciona tão bem, por que seus projetos são apresentados da maneira que funcionam.

Outra preocupação é o grau de perfeição debatido com o qual é preciso fazer TDD para fazê-lo com sucesso. Alguns insistem que, se o TDD não for feito persistentemente por todos da equipe desde o início do projeto, você só sofrerá. Outros insistem que ninguém faz TDD pelo livro. Se ambos são verdadeiros, segue-se que os praticantes de TDD estão sofrendo, percebendo ou não.

Obviamente, se estiver sendo argumentado que, ao fazer as coisas de maneira semelhante ao TDD, você encontrará projetos que podem funcionar facilmente com o TDD, bem, existem maneiras muito mais rápidas de conseguir isso - ou seja, estudando realmente os conceitos de composição. Existem muitos recursos por aí, muita teoria matemática rigorosa (em grande parte em programação funcional, mas também em outros campos). Por que não gastar todo o seu tempo TDD aprendendo ?

Culturalmente, o TDD mostra sintomas de ser uma prática ritualística. Ele cavalga por culpa; incentiva o procedimento acima da compreensão; ele tem toneladas de doutrinas e slogans ("fingir até que você faça" é realmente muito alarmante se você olhar objetivamente). A definição da Wikipedia da palavra "ritual" é de fato bastante apropriada:

Em psicologia, o termo ritual às vezes é usado em um sentido técnico para um comportamento repetitivo usado sistematicamente por uma pessoa para neutralizar ou prevenir a ansiedade; é um sintoma de transtorno obsessivo-compulsivo.

Rei Miyasaka
fonte
Perspectiva muito interessante sobre o ritual. Você também tem a sensação, em alguns círculos, de que o comprometimento de um programador com seu ofício é considerado proporcional à sua adesão ao TDD.
Yalestar
Eu diria que, em algumas situações, ele pode melhorar um design, mas principalmente é quando o design precisa ser altamente modular, com uma interface pública muito bem definida e fácil de usar. Escrever os testes antes de implementar a própria biblioteca nesses casos pode ajudar a resolver os bugs na interface pública e forçar essa modularidade.
jwenting
8
@jwenting As pessoas fazem TDD porque não sabem o que faz um design modular, para que nunca possam tirar suas rodas de treinamento de 35 "de suas bicicletas de 40". Criar um design modular é sempre uma tarefa gerenciável se você entender os conceitos, porque cada dilema em seu design terá um tamanho gerenciável devido ao fato de estar, em sua concepção, no processo de se tornar modular. Não discordo que o TDD seja eficaz em forçar a modularidade, mas discordo que é preciso ser forçado a criar projetos modulares. O design modular é uma habilidade perfeitamente ensinável e aprendível.
Rei Miyasaka 10/08
@jwenting Em relação à usabilidade das interfaces públicas, há duas escolas de pensamento entre os profissionais de TDD: ambas são indesejáveis: tornar público tudo para que possa ser testado ou deixar as coisas privadas, caso não devam ser testadas de qualquer maneira. . O primeiro força os detalhes desnecessários da implementação a serem expostos aos usuários finais (que podem potencialmente ser mal utilizados ou explorados) e o segundo força os testes de unidade a estarem mais próximos dos testes do sistema. Claro, você poderia usar ferramentas de teste de unidade para acessar privates, mas isso não faz muito sentido no TDD.
Rei Miyasaka 10/08
1
@Kall Na entrevista, ele diz "cerca de 15 a 35% mais tempo" - e não apenas 15%, como você citou. O estudo também envolve apenas Java / C ++ / C # (provavelmente C # 2, dada a data) - todas as linguagens do mesmo paradigma imperativo de POO. Tenho certamente mais de 15% e provavelmente mais de 35% de produtividade em uma linguagem funcional (e até em C # 3), e produzo muito menos bugs escrevendo código sem estado e compostável - os mesmos tipos de bugs que os testes melhoram, porque as duas coisas resolvem exatamente os mesmos tipos de problemas. Em outras palavras, com certeza, 60-90% de redução de bugs, mas em comparação com o que ?
Rei Miyasaka 28/10
18

Para acrescentar, outra preocupação com o TDD que notei é:

O TDD causa uma mudança inadvertida no foco da equipe de desenvolvimento de Código de Qualidade para Casos de Teste e Cobertura de Código! Pessoalmente, não gostei do TDD, pois me torna menos criativo e torna o desenvolvimento de software um processo mecânico monótono ! Os casos de teste de unidade são úteis quando usados ​​criteriosamente, mas se tornam um fardo quando tratados como o objetivo do desenvolvimento de software.

Conheço um cara que é gerente e tecnicamente monótono uma vez ficou obcecado por TDD. Foi uma coisa tão mágica para ele que ele acreditava que traria soluções mágicas para todos os problemas em seu software mal arquitetado, com código menos sustentável. Para não dizer o que aconteceu com esse projeto - ele falhou miseravelmente em suas mãos, enquanto todas as suas caixas de teste eram verdes. Eu acho que o TDD o ajudou a obter algum tipo de informação estatística como "99/100 dos meus casos são verdes" etc. e esse foi o motivo de sua obsessão, pois ele nunca seria capaz de avaliar a qualidade ou sugerir melhorias no design.

Kiran Ravindranathan
fonte
2
Parece o inferno da PHB! Isso me lembra as empresas que introduzem esquemas de bônus - o que acontece, é claro, é que os desenvolvedores, em vez de se concentrarem no código de qualidade, se concentram em atender aos requisitos de bônus. Inevitavelmente, você obtém um código de baixa qualidade. (Há também uma analogia aqui para a corrente :-) crise bancária)
TrojanName
Bem, o TDD não é uma técnica de gerenciamento de projetos, portanto, não é de admirar que o seu gerente-aspirante tenha falhado. Por outro lado, não me sinto menos criativo, sinto-me ainda mais criativo, porque o desenvolvimento de testes automaticamente me dá outra visão do meu código. No entanto, concordo que o foco deve ser o código de produção, e os testes não devem atrapalhar uma boa arquitetura de software.
25411 Alex
A cobertura do código é uma preocupação do Teste de Unidade, não do TDD. O TDD se preocupa apenas com recursos e testes através de interfaces públicas.
Steven A. Lowe
14

Minha principal experiência negativa é tentar usar o TDD para editar o código de outro programador que não possui testes ou testes de integração muito, muito básicos. Quando vou adicionar um recurso ou corrigir um problema com o referido código; Eu preferiria escrever um teste primeiro (da maneira TDD). Infelizmente, o código está fortemente associado e não posso testar nada sem muita refatoração.

De qualquer forma, a refatoração é um ótimo exercício, mas é necessário que o código fique em um estado testável. E após esta etapa, não tenho freios e contrapesos para ver se minhas alterações quebraram alguma coisa; falta de executar o aplicativo e examinar todos os casos de uso.

Por outro lado, adicionar recursos / corrigir bugs a um projeto TDD se torna muito simples. Por natureza, o código escrito com TDD geralmente é bastante dissociado com pequenos pedaços para trabalhar.

De qualquer forma, o TDD é uma diretriz. Siga-o até o ponto em que você obtém a máxima eficácia. Cobertura de teste decente e código desacoplado, código bem escrito.

Sheldon Warkentin
fonte
1
Se for difícil escrever testes de unidade, geralmente há pouca separação de preocupações. Não vejo isso como culpa do TDD, se algo rapidamente torna esses problemas óbvios.
Tom Kerr
7
Essa não é uma experiência negativa com TDD, é uma experiência negativa com código de baixa qualidade.
Rei Miyasaka
13

Fiz a experiência de que às vezes confio demais nos meus testes quando se trata do design do sistema. Eu sou basicamente muito baixo nos detalhes da implementação, para dar um passo atrás e olhar para o cenário mais amplo. Isso geralmente resulta em um design desnecessariamente complexo. Eu sei, devo refatorar o código, mas às vezes tenho a impressão de que poderia economizar muito tempo dando o passo para trás com mais frequência.

Dito isto, se você tiver uma estrutura como trilhos em que suas decisões de arquitetura são muito limitadas, esses problemas são basicamente inexistentes.

Outro problema é quando você confia cegamente em seus testes. A verdade é - como qualquer outro código - seus testes também podem ter erros. Portanto, seja tão crítico em relação aos seus testes quanto em sua implementação.

sebastiangeiger
fonte
2
Talvez você deva escrever alguns testes para os seus testes! : p ...... I Kid, I Kid
Aren
+1 +1 +1 +1 (se eu tivesse 3 contas falsas). A frase 2 é muito perspicaz e livre do viés de confirmação do TDD, que é muito prevalente.
tgm1024 7/04
11

Como um grande fã de TDD, às vezes vejo essas desvantagens

  • Tentação de escrever muitos testes em nome de quase 100% de cobertura de código. Na minha opinião, não é necessário escrever testes
    • para getters / setters simples de propriedades
    • para todos os casos em que uma exceção é lançada
    • que verifica a mesma funcionalidade através de diferentes camadas. (Exemplo: se você tiver um pouco para verificar a validação de entrada para cada parâmetro, não será necessário repetir todos esses testes também por meio de um teste de integração)
  • Custos de manutenção do código de teste para testes semelhantes, que variam apenas um pouco (criados através da duplicação de código (também conhecida como herança de copiar e colar)). Se você já possui um, é fácil criar um semelhante. Mas se você não refatorar o código de teste, eliminando a duplicação de código em métodos auxiliares, poderá ser necessário algum tempo para corrigir os testes se os detalhes de implementação do seu código de negócios forem alterados.

  • Se você estiver sob pressão do tempo, pode ser tentado a eliminar testes quebrados (ou comentá-los) em vez de corrigi- los. Dessa forma, você perde o investimento nos testes

k3b
fonte
2
+1: "Tentação de escrever muitos testes em prol de quase 100% de cobertura de código.": Caí nessa armadilha uma vez e, depois de passar tantas horas escrevendo todos esses testes de unidade, os únicos três erros que encontrei no meu código foram não é coberto pelos testes de unidade e pode ser facilmente encontrado depurando o código passo a passo.
Giorgio
9

Ainda tenho que encontrar mais de um cenário como desenvolvedor de jogos em que o TDD valeu a pena. E o exemplo em que estava, era um pedaço de código puramente matemático por natureza e precisava de uma abordagem sólida para testar um grande número de casos extremos simultaneamente - uma necessidade rara.

Talvez alguma coisa, algum dia, mude de idéia, mas, entre as práticas do XP, a idéia de refatorar impiedosamente e de código que desenvolve sua própria forma é muito mais importante e leva à maior produtividade para mim, cf. uma citação de um artigo de James Newkirk :

Simplicidade - "Qual é a coisa mais simples que poderia funcionar?"
A mensagem é muito clara. Dado os requisitos de hoje, projete e escreva seu software. Não tente antecipar o futuro, deixe o futuro se desdobrar. Isso geralmente é feito de maneira imprevisível, tornando a antecipação um custo que muitas vezes é muito caro para pagar ".

Os conceitos de coragem e de apertar laços de feedback que ele menciona também são, na minha opinião, essenciais para a produtividade.

Engenheiro
fonte
9
O problema é que, sem testes de unidade, como você sabe que sua refatoração impiedosa resulta em código que faz a mesma coisa? Na minha experiência, descobri que, dependendo do problema, levo menos tempo para escrever testes + código do que escrever sozinho! O motivo se resume principalmente ao fato de que, para alguns problemas, eu posso experimentar um redator e testar novamente muito mais rapidamente do que eu poderia testá-lo manualmente, o que pode aumentar significativamente a velocidade das iterações.
Mark Booth
6
Para jogos, muitas vezes os resultados podem ser vistos. Se eles puderem ser vistos e parecerem bons o suficiente, serão aceitos, já que um jogo pretende ser uma experiência subjetiva de qualquer maneira. Por outro lado, tendo por exemplo. Diablo 2 como exemplo, o número de erros nas fórmulas de combate mostrou onde o TDD teria trazido grande valor e economizado uma grande quantidade de trabalho em patches. Para problemas muito bem definidos, como resolver equações, e onde eles não podem ser julgados por saídas visuais em tempo de execução, o TDD é um item obrigatório para garantir a correção. Mas isso é uma pequena fração do código na maioria dos jogos.
Engenheiro de
Também vale mencionar que, devido à taxa em que as simulações são executadas, é melhor observar variáveis ​​em tempo real, na tela, enquanto o sim é executado, do que ficar sentado com arquivos de log de milhões de linhas para examinar o fato.
Engenheiro de
3
Testes de unidade tornam a refatoração muito mais fácil, na minha experiência.
Tom Kerr
1
@ Nick O grande problema na indústria de jogos são os prazos, que são sempre - "tivemos que entregar meio ano atrás". Acho que o tempo joga contra testes de unidade em ambientes com tempo limitado. Em alguns casos, não é uma decisão correta, mas na maioria dos casos o envio sem a gravação do teste é mais rápido. Depende, realmente depende ...
Coder
7

Minha experiência negativa no TDD, por mais limitada que seja, é simplesmente saber por onde começar! Por exemplo, tentarei fazer algo TDD e não tenho idéia de onde começar a barrar o teste de coisas triviais (posso criar um Fooobjeto novo , posso passar um Quuxpara o Baze assim por diante . Testes que não testam nada ) ou se estou tentando implementá-lo em um projeto existente, acho que precisaria reescrever várias classes para poder usá-las no TDD. O resultado final é que eu rapidamente abandono completamente a noção.

Provavelmente não ajuda que muitas vezes eu seja a única pessoa em toda a empresa que saiba o que é o teste de unidade (TDD ou não) e por que é uma coisa boa.

Wayne Molina
fonte
1
É aqui que as estruturas de simulação entram em ação. Instancie Foocom objetos Mock em vez de Quuxe Bazdiretamente, então você poderá chamar a função que deseja testar e verificar se os mock foram chamados com as funções que você espera. Objetos simulados são a tecnologia capacitadora que ajuda a desacoplar unidades e torná-las testáveis. É por isso que os singletons são maus, pois muitas vezes você não pode simplesmente zombar deles. * 8 ')
Mark Booth
7

Fanáticos de TDD.

Para mim, eles são apenas uma de uma longa fila de loucos religiosos batendo na minha porta, tentando provar que minha maneira de fazer as coisas é irreparavelmente quebrada e o único caminho para a salvação é Jesus, Kent Back ou Unit Testing.

Na IMO, a maior mentira é que o TDD levará você a salvar um melhor design de algoritmo. Veja o famoso solucionador de Soduku escrito em TDD: aqui , aqui , aqui , aqui e aqui

E compare-o com o solucionador de Peter Norvig sudoku, não usando TDD, mas usando engenharia antiquada: http://norvig.com/sudoku.html

Cesar Canassa
fonte
Olha, nós poderíamos discutir sobre isso. Mas tenho muito trabalho a fazer desde que me formei na universidade Fullsail com meu diploma em design de jogos. Com base em meus cursos e em meu trabalho muito exigente, posso dizer que o TDD realmente supera o frenético desenvolvimento linha a linha (falta de design) de programadores preguiçosos. Olha, eu não diria isso, mas é verdade: a maioria dos desenvolvedores que frequentaram o programa de CS de uma universidade normal geralmente não se formou, os poucos que fizeram a maior parte do tempo não se dedicaram ao desenvolvimento de software e, além disso, muitos deles mal conseguem sobreviver. , linha por linha. Universidade Fullsail tem um
Zombies
curso completo apenas em desenvolvimento orientado a testes e que realmente coloca os desenvolvedores no caminho certo (em vez de implementar uma lista vinculada em c ++).
Zombies
Links estão quebrados cara!
Lmiguelvargasf
Isso ocorre muitos anos depois, mas o @Zombies, analisa "Viés de confirmação". Muito do que todos nós somos ensinados no ensino médio na faculdade se encaixa exatamente nessa categoria. Dê uma olhada na rejeição
imediata
Lol cara, eu estava trollando ... eu escrevi que há muito tempo eu tinha esquecido aquela pequena jóia.
Zombies
5

Se você usar o TDD desses artigos "fanáticos", ficará com a segurança errada, sentindo que o seu software não possui erros.

Dainius
fonte
1
Você pode ter outro sentimento além de saber que, para um determinado conjunto de entradas, seu software retorna um determinado conjunto de saídas?
Desde que você entenda que tdd é um processo de desenvolvimento e não uma regra de ouro para resolver qualquer tipo de problema, tudo bem. Mas a maioria das pessoas que se propõe a usar esse processo esqueceu que é um processo de desenvolvimento e, como qualquer outro processo, tem um lado positivo e um lado sombrio. Eles estão dizendo para todos que, se você usar o tdd, terá um software livre de erros, porque usará o teste para cobrir todos os recursos. E geralmente não está certo. Da melhor maneira, haverá teste para cada caso (ou pelo menos recurso), mas testes são programas (que possuem bugs) e são apenas testes de caixa preta.
Dainius
4

TDD tem alguns benefícios:

  • Você se concentra em como chamar seu código e o que esperar primeiro (ao escrever o teste primeiro), em vez de se concentrar em resolver o problema e, em seguida, cola em uma chamada do aplicativo. A modularidade facilita a simulação e a quebra.
  • Os testes garantem que seu programa funcione da mesma forma antes e após uma refatoração. Isso não significa que seu programa está livre de erros, mas continua funcionando da mesma maneira.

TDD é sobre investimento de longo prazo. O esforço compensa quando você alcança o modo de manutenção do seu aplicativo e, se o aplicativo não estiver planejado para atingir esse ponto, você nunca poderá recuperar o investimento.

Considero o ciclo vermelho-verde do TDD com os pequenos passos semelhantes a uma lista de verificação para um avião. É chato e tedioso verificar tudo no avião antes da decolagem, especialmente se for trivialmente simples (os passos do bebê TDD), mas foi constatado que aumenta a segurança. Além de verificar se tudo funciona, redefine essencialmente o avião . Em outras palavras, um avião é reiniciado antes de cada decolagem.

user1249
fonte
3
O ponto de benefício 2 pode ser alcançado com testes de unidade simples, sem uma abordagem TDD também. Benefício 1, você deve estar fazendo de qualquer maneira. (Focando na API) Ainda é totalmente possível criar uma API de baixa qualidade usando TDD, mas sim, você tem certeza de que ela funcionará (para os testes escritos).
Steven Jeuris
2
A questão não era perguntar sobre os benefícios do TDD. Já existem muitas outras perguntas sobre isso.
Aaronaught
1
@ Aaronaught, estou abordando seus pontos de dor.
As respostas devem abordar a questão .
Aaronaught 4/08/11
1
@aaronaught, depois escreva alguns deles.
3

Minha experiência negativa sobre TDD é algo que sinto com muitas coisas novas e sensacionalistas. Na verdade, eu gosto do TDD porque ele garante a validade do meu código e ainda mais importante: eu reconheço os testes com falha depois de adicionar um novo código ou qualquer tipo de refatoração.

O que me incomoda no TDD é o fato de que existem muitas regras ou diretrizes sobre isso. Como ainda é bastante novo, muitos de nós experimentamos ser iniciantes no TDD. Então, o que funciona bem para alguns de nós pode não funcionar para outros. O que eu quero dizer é que não existe uma maneira "certa ou errada" real de executar o TDD: existe a maneira que funciona para mim - e minha equipe, se eu tiver uma.

Portanto, desde que você escreva testes - antes ou depois do código de produção não importa realmente o IMHO -, não tenho certeza se o teste conduzido realmente significa que você deve seguir todas as diretrizes indicadas agora, uma vez que elas ainda não foram comprovadas. a solução ideal para o trabalho diário. Se você encontrar uma maneira melhor de escrever testes, publique-o em um blog, discuta-o aqui ou escreva um artigo sobre ele. Assim, em dez anos ou mais, poderíamos ter compartilhado experiência suficiente para poder dizer qual regra do TDD pode ser considerada boa ou não em uma determinada situação.

Alex
fonte
+1 Excelente comentário. Realmente não precisa ser a única maneira verdadeira ou nenhuma maneira.
Unpythonic
3

Em mais de uma ocasião, escrevi um código que descartei no dia seguinte, uma vez que era desajeitado. Eu reiniciei com TDD e a solução era melhor. Então, eu não tive muito na linha de experiência negativa no TDD. No entanto, dito isso, passei um tempo pensando em um problema e encontrando uma solução melhor fora do espaço TDD.

user23356
fonte
1
Normalmente, uma segunda tentativa forneceria mais informações sobre o problema do que a primeira tentativa, TDD ou não.
Wobbily_col
3

Eu descobri que o TDD tem um desempenho ruim quando se trata de sistemas emergentes. Sou desenvolvedor de videogames e recentemente usei o TDD para criar um sistema que usa vários comportamentos simples para criar um movimento realista para uma entidade.

Por exemplo, existem comportamentos responsáveis ​​por afastá-lo de áreas perigosas de diferentes tipos e responsáveis ​​por movê-lo para áreas interessantes de diferentes tipos. Amalgamar a saída de cada comportamento cria um movimento final.

As tripas do sistema foram implementadas facilmente, e o TDD foi útil aqui para especificar o que cada subsistema deve ser responsável.

No entanto, tive problemas ao especificar como os comportamentos interagem e, mais importante, como eles interagem com o tempo. Muitas vezes, não havia resposta certa e, embora meus testes iniciais estivessem passando, o controle de qualidade continuava encontrando casos extremos onde o sistema não funcionava. Para encontrar a solução correta, eu tive que repetir vários comportamentos diferentes e, se eu atualizasse os testes a cada vez para refletir os novos comportamentos antes de verificar se eles funcionavam no jogo, talvez eu acabasse jogando fora os testes várias vezes. Então eu apaguei esses testes.

Eu deveria ter tido testes mais fortes que capturaram os casos extremos que o controle de qualidade descobriu, mas quando você tem um sistema como esse que fica no topo de muitos sistemas de física e jogabilidade, e está lidando com comportamentos ao longo do tempo, isso se torna um pouco pesadelo para especificar exatamente o que está acontecendo.

Eu quase certamente cometi erros na minha abordagem e, como disse para o interior do sistema, o TDD funcionou brilhantemente e até apoiou alguns refatores otimizadores.

tenpn
fonte