Por que o desenvolvimento orientado a testes está ausente do Teste de Joel?


23

Eu estava lendo este blog por Joel Spolsky cerca de 12 etapas para melhorar o código . A ausência de desenvolvimento orientado a testes realmente me surpreendeu. Então, eu quero fazer a pergunta para os Gurus. O TDD realmente não vale o esforço?


13
Esse artigo foi escrito quarta-feira, 9 de agosto de 2000 (cerca de 12 anos atrás). Não que o TDD não estivesse por perto naquele momento, mas não acredito que tenha gostado quase do burburinho que faz atualmente.
Mike

12
O teste de Joel é apenas um conjunto de diretrizes genéricas. Nem tudo o que "vale o esforço" pode caber lá.
precisa

2
Eu criei meu próprio teste altamente irresponsável e desleixado para avaliar a qualidade de uma equipe de software. A grande parte disso é que leva cerca de 3 minutos ... O interessante do The Joel Test é que é fácil obter um sim ou não rápido para cada pergunta. Você não precisa descobrir linhas de código por dia ou bugs médios por ponto de inflexão ... ' - decidir se seu projeto se beneficiará do TDD levaria mais de 3 minutos e, bem, , pode exigir figurando média-bugs-por-inflexão ponto - é por isso que não está na lista
mosquito

Vá para Joel Stack plz. É um q interessante.
Erik Reppen

Você deve aceitar a resposta que vincula e cita diretamente de Joel, pois ela não tem mais autoridade do que isso. Veja programmers.stackexchange.com/a/189493/6586
Bryan Oakley

Respostas:


30

O desenvolvimento orientado a testes era praticamente desconhecido antes do livro de Kent Beck ser lançado em 2002, dois anos depois que Joel escreveu esse post. A questão então se torna: por que Joel não atualizou seu teste, ou se o TDD fosse mais conhecido em 2000, ele o incluiria entre seus critérios?

Acredito que ele não teria, pela simples razão de que o importante é que você tenha um processo bem definido, não os detalhes específicos desse processo. É a mesma razão pela qual ele recomenda o controle de versão sem especificar um sistema de controle de versão específico ou recomenda ter um banco de dados de erros sem recomendar uma marca específica. As boas equipes aprimoram e se adaptam continuamente e usam ferramentas e processos adequados para sua situação específica naquele momento específico. Para algumas equipes, isso definitivamente significa TDD. Para outras equipes, nem tanto. Se você adotar o TDD, verifique se não está fora de uma mentalidade de culto à carga .


1
Além disso ... oh, você acertou um pouco o TDD é o ponto Kool Aid, não é?
Erik Reppen


27

Joel realmente abordou isso especificamente em alguns lugares.

Ele explicou que os testes de coisas não são capazes de captar muitas questões importantes, principalmente as subjetivas, como "a interface do usuário deste software é péssima?" Segundo ele, a dependência excessiva de testes automatizados na Microsoft é como acabamos com o Windows Vista.

Ele escreveu como, em sua experiência, os tipos de bugs que os usuários realmente encontram tendem a se dividir em duas categorias: 1) os que aparecem em uso comum, que os programadores teriam encontrado se tivessem executado seu próprio código antes de usá-lo ou 2) casos extremos tão obscuros que ninguém teria pensado em escrever testes para cobri-los em primeiro lugar. Ele afirmou que apenas uma porcentagem muito pequena dos erros que ele e sua equipe corrigem no FogBugz são o tipo de coisa que os testes de unidade teriam detectado. (Não consigo encontrar esse artigo agora, mas se alguém souber qual deles eu quero dizer, fique à vontade para editar o link aqui.)

E ele escreveu como isso pode ser mais problemático do que vale a pena, especialmente quando o seu projeto cresce em um projeto muito grande com muitos testes de unidade, e então você muda algo (intencionalmente) e acaba com um número muito grande de testes de unidade quebrados. Ele usa especificamente os problemas que o teste de unidade pode causar como a razão pela qual ele não o adicionou como um 13º ponto ao Teste de Joel, mesmo quando as pessoas sugerem que ele deveria.


2
Na verdade, você está certo. O MO habitual de Joel é o homem de palha. Como o TDD não teria detectado nenhum erro para mim, então não pode ser bom. O que de certa forma esquece o ponto em que o TDD não é sobre testes, é sobre design. Os testes deixados para trás são um bônus. Ou argumentar que uma pequena mudança interromperá muitos testes de unidade, o que sugere que ele está fazendo errado. Ou reescrever completamente um princípio do SOLID antes de atacá-lo. Aquele tipo de coisa. Na verdade, são seus proponentes que usam a lógica circular, não ele.
PDR

7
Concordo plenamente com esses comentários de Joel. Acho que um problema ainda maior é a linguagem - com muitas linguagens dinâmicas que não consigo imaginar fazer nada sem testes de unidade - de que outra forma você pode dizer se um simples erro de digitação causará algum problema que você não verá até que seja crítico momento? Nas linguagens compiladas estaticamente, projetadas para reduzir os erros, você se afasta de todos os erros mais simples e fica principalmente com erros lógicos. Isso reduz a necessidade do tipo de cobertura total fornecida pelo TDD.
Bill K

2
@MasonWheeler: Você está argumentando seriamente que a segurança do compilador / tipo elimina a necessidade de testes de unidade? Você também está ignorando intencionalmente os benefícios de design do TDD, mas, o mais importante, você deve passar muito tempo refatorando qualquer coisa. Em vez disso, o oposto foi visto como verdadeiro: por exemplo, desenvolvedores .NET que seguem uma metodologia TDD repentinamente se vêem frustrados com a quantidade de código que precisam escrever para agradar a um compilador que é cada vez mais inútil.
PDR

2
@pdr: Estou seriamente argumentando que "a necessidade de testes de unidade" em primeiro lugar é a falta de segurança do tipo. E, não sendo desenvolvedor de .NET, não posso dizer muito sobre suas experiências, mas, em minha própria experiência, descobri que a dificuldade na refatoração se baseia inteiramente em dois fatores: se eu escrevi ou não o código no primeiro local e se o autor escreveu ou não o código corretamente. (Nota: os pontos 1 e 2 não são necessariamente fortemente correlacionada com o outro!)
Mason Wheeler

3
Os testes de unidade @Pdr não provam seu código, são principalmente um verificador de sintaxe, mas podem ser muito úteis durante o desenvolvimento. Os testes de integração e sistema fazem muito mais sentido. Além disso, a maioria das refatorações em linguagens de tipo estaticamente pode ser comprovadamente segura, na verdade é isso que é uma refatoração - um conjunto de operações "seguras" conhecidas que transformam seu código sem introduzir alterações. Em uma linguagem estática, o IDE muitas vezes pode fazer essas alterações para você e garantir que elas sejam seguras, algo geralmente impossível em linguagens dinâmicas que, portanto, exigem testes de unidade para ajudar (não provar) a mesma segurança
Bill K

25

O próprio Joel Spolsky respondeu a essa pergunta em 2009 :

Joel: Há um debate sobre o desenvolvimento orientado a testes ... você deve fazer testes unitários para tudo, esse tipo de coisa ... muitas pessoas me escrevem, depois de ler o teste Joel, para dizer: "Você deveria ter um 13º coisa aqui: Teste de Unidade, 100% de testes de unidade de todo o seu código. "

E isso me parece um pouco doutrinário demais sobre algo que você pode não precisar. Assim, toda a idéia de programação ágil não é fazer as coisas antes que você precise delas, mas sim criar uma falha de página, conforme necessário. Sinto que o teste automatizado de tudo, muitas vezes, simplesmente não vai ajudá-lo. Em outras palavras, você escreverá muitos testes de unidade para garantir que o código realmente funcione, e você definitivamente descobrirá se ele não funciona [se você não escreva os testes] funciona, na verdade ainda funciona, ... eu não sei, vou receber mensagens de chamas por isso porque não estou expressando muito bem. Mas sinto que, se uma equipe realmente tivesse 100% de cobertura de código em seus testes de unidade, haveria alguns problemas. 1, eles gastariam muito tempo escrevendo testes de unidade e não seriam necessariamente capazes de pagar por esse tempo com melhor qualidade. Quero dizer, eles teriam uma qualidade melhorada e teriam a capacidade de mudar as coisas em seu código com a confiança de que não quebram nada, mas é isso.

Mas o verdadeiro problema com os testes de unidade, como descobri, é que o tipo de alterações que você tende a fazer à medida que o código evolui tende a quebrar uma porcentagem constante de seus testes de unidade. Às vezes, você faz uma alteração no seu código que, de alguma forma, quebra 10% dos seus testes de unidade. Intencionalmente. Porque você mudou o design de algo ... mudou um menu e agora tudo o que contava com esse menu estava lá ... o menu está agora em outro lugar. E então todos esses testes agora são interrompidos. E você deve poder recriar esses testes para refletir a nova realidade do código.

Portanto, o resultado final é que, à medida que seu projeto aumenta, se você realmente tiver muitos testes de unidade, a quantidade de investimento que você terá que fazer para manter esses testes de unidade, mantê-los atualizados e manter eles passando, começa a se tornar desproporcional à quantidade de benefícios que você obtém deles.


2
Sério? Votos negativos em postar a resposta de Joel à pergunta do OP?
Ross Patterson

1
Difícil de entender. Algumas pessoas usam o voto para significar "eu aprovo" em vez de "isso é útil". Obviamente, essa deve ser a resposta aceita, porque é definitiva.
Bryan Oakley

Nunca trabalhei em um projeto que tivesse 100% de cobertura de teste. Mas se você tem 0% de cobertura de teste ... ... isso é bastante revelador.
Kzqai

Obrigado! Eu acho que isso deve ser marcado como resposta aceita.
Jalal

5

Ninguém além de Joel poderia responder isso com certeza. Mas podemos tentar algumas razões / observações.

Primeiro de tudo, o teste não está ausente no teste de Joel

  • Os testes são mencionados duas vezes em 12 etapas diretamente (10 e 12)
  • A existência de uma compilação é um dos primeiros pontos. A idéia de ter o build é ter a capacidade de ver se eles quebram, então estamos (também) falando sobre testes aqui.

Em segundo lugar, toda a idéia do teste Joel (como eu o entendo) é ter perguntas rápidas, sim-não. "Você faz TDD?" não se encaixará exatamente (a resposta pode ser: "alguns de nós", "para essa parte do código" ou "fazemos teste de unidade".

Em terceiro lugar, acho que ninguém disse que (mesmo Joel) que aqueles pontos em que "os únicos que valem tempo" (a propósito, "você programa" não estão nele), apenas que essas são boas perguntas rápidas a serem feitas quando chegar entrar em contato com uma equipe de software, seja como futuro membro da equipe ou até como cliente - esta é uma lista que eu dei a algumas pessoas não técnicas ao meu redor que procuravam pistas sobre o quão bom / ruim era seu próprio departamento de TI. Não é tudo, mas é muito ruim vencer em três minutos.


3
"Você faz TDD?" certamente se encaixa como uma pergunta sim-não. E com isso quero dizer que é uma pergunta que todos respondem com um enfático "sim", que na verdade significa "não".
precisa

2
@YannisRizos: Muito parecido com "Você usa as melhores ferramentas que o dinheiro pode comprar?" (Sim ... tudo bem ... dentro do razoável.) E "Os programadores têm condições de trabalho silenciosas?" (Ohhhh sim ... wellllll ... depende do seu ponto de referência para o silêncio, eu acho.)
PDR

@pdr Depende se você considera silencioso o som de sirenes entrando pelas janelas abertas.
Robert Harvey

Além disso, "Sim, eu faço design de cima para baixo ". ;)
Izkata
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.