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

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?

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 .

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.

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.

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.