O teste de unidade me parece ótimo, mas não tenho certeza se devo dedicar algum tempo para aprendê-lo, a menos que consiga convencer os outros de que tem um valor significativo. Eu tenho que convencer os outros programadores e, mais importante, os contadores de feijão no gerenciamento, que todo o tempo extra gasto aprendendo a estrutura de teste, escrevendo testes, mantendo-os atualizados, etc.

Que prova existe? Alguém realmente desenvolveu o mesmo software com duas equipes separadas, uma usando testes de unidade e a outra não, e comparou os resultados? Eu duvido. Devo justificá-lo com "Procure na Internet, todo mundo está falando sobre isso, então deve ser a coisa certa a fazer"?

Onde estão as evidências concretas que convencerão os leigos de que o teste de unidade vale a pena?

Sim. Este é um link para um estudo de Boby George e Laurie Williams no NCST e outro de Nagappan et al. Tenho certeza que existem mais. As publicações do Dr. Williams sobre testes podem fornecer um bom ponto de partida para encontrá-las.

[EDIT] Os dois artigos acima referenciam especificamente o TDD e mostram um aumento de 15 a 35% no tempo de desenvolvimento inicial após a adoção do TDD, mas uma redução de 40 a 90% nos defeitos de pré-lançamento. Se você não consegue obter as versões em texto completo, sugiro usar Google Scholar para ver se você encontra uma versão disponível ao público.

"Eu tenho que convencer os outros programadores e, mais importante, os contadores de feijão no gerenciamento, que todo o tempo extra gasto aprendendo a estrutura de teste, escrevendo testes, mantendo-os atualizados, etc. se pagará por si próprio e mais. "

Por quê?

Por que não fazê-lo, discretamente e discretamente? Você não precisa fazer tudo de uma vez. Você pode fazer isso em pequenos pedaços.

O aprendizado da estrutura leva muito pouco tempo.

Escrever um teste, apenas um, leva muito pouco tempo.

Sem testes de unidade, tudo que você tem é um pouco de confiança no seu software. Com um teste de unidade, você ainda tem sua confiança, além de uma prova de que pelo menos um teste passa.

Isso é tudo o que preciso. Ninguém precisa saber que você está fazendo isso. Apenas faça.

Eu adoto uma abordagem diferente para isso:

Que garantia você tem de que seu código está correto? Ou que não quebra a suposição X quando alguém da sua equipe altera func1 ()? Sem testes de unidade mantendo você "honesto", não tenho certeza de que você tenha muita garantia.

A noção de manter os testes atualizados é interessante. Os testes em si muitas vezes não precisam mudar. Eu tenho 3x o código de teste comparado ao código de produção, e o código de teste foi alterado muito pouco. É, no entanto, o que me permite dormir bem à noite e o que me permite dizer ao cliente que tenho confiança de que posso implementar a funcionalidade Y sem interromper o sistema.

Talvez na academia haja evidências, mas nunca trabalhei em nenhum lugar do mundo comercial em que alguém pagaria por esse teste. Posso dizer, no entanto, que funcionou bem para mim, demorou pouco tempo para me acostumar com a estrutura de teste e o teste de escrita me fez realmente pensar nos meus requisitos e no design, muito mais do que nunca quando trabalhei em equipes que não escreveu testes.

Aqui é onde ele se paga: 1) Você confia no seu código e 2) Você encontra problemas mais cedo do que faria de outra maneira. Você não tem o cara do controle de qualidade dizer "ei, você não se incomodou em verificar a função xyz (), não é? Ele não consegue encontrar esse bug porque você encontrou há um mês. Isso é bom para ele, bom para você, bom para a empresa e bom para o cliente.

Claramente, isso é anedótico, mas fez maravilhas para mim. Não tenho certeza se posso fornecer planilhas, mas meu cliente está satisfeito e esse é o objetivo final.

Demonstramos com evidências concretas que é possível escrever software ruim sem teste de unidade. Acredito que há até evidências de software ruim com o Teste de Unidade. Mas esse não é o ponto.

O Teste de Unidade ou Desenvolvimento Orientado a Testes (TDD) é uma técnica de Design, não uma técnica de teste. O código que é escrito baseado em teste é completamente diferente do código que não é.

Mesmo que essa não seja sua pergunta, pergunto-me se é realmente a maneira mais fácil de seguir adiante e responder perguntas (e trazer evidências que possam ser contestadas por outros relatórios) que possam ser feitas de maneira errada. Mesmo se você encontrar evidências concretas para o seu caso - alguém poderá encontrar evidências concretas contra.

O negócio dos contadores de feijão é determinar como o pessoal técnico deve trabalhar? Eles estão fornecendo as ferramentas mais baratas em todos os casos porque acreditam que você não precisa de ferramentas mais caras?

Esse argumento é ganho com base na confiança (um dos valores fundamentais das equipes ágeis) ou perdido com base no poder do papel da parte vencedora. Mesmo que os proponentes do TDD ganhem com base no poder do papel, eu o consideraria perdido.

Se você também estiver interessado em evidências contra testes de unidade, aqui está um artigo bem pesquisado e pensado:

Por que a maioria dos testes de unidade é desperdício James O Coplien (guru enxuto e ágil)

Mais sobre TDD do que testes estritamente unitários, aqui está um link para a Realização da melhoria da qualidade por meio do desenvolvimento orientado a testes: resultados e experiências de quatro equipes industriais , por Nagappan, E. Michael Maximilien, Thirumalesh Bhat e Laurie Williams. artigo publicado pelo grupo ESM ( Microsoft Empirical Software Engineering and Measurement ) e já mencionado aqui.

A equipe descobriu que as equipes do TDD produziram código entre 60% e 90% por cento melhor (em termos de densidade de defeitos) do que as equipes que não são do TDD. No entanto, as equipes de TDD demoraram entre 15% e 35% a mais para concluir seus projetos.

Aqui está uma leitura ótima e divertida de um cara mudando sua empresa por dentro. Não se limita ao TDD. http://jamesshore.com/Change-Diary/ Observe que ele não convenceu os "contadores de feijões" por um bom tempo e, em vez disso, usou "táticas de guerrilha".

Apenas para adicionar mais informações a essas respostas, existem dois recursos de metanálise que podem ajudar a descobrir os efeitos de produtividade e qualidade nos antecedentes acadêmicos e do setor:

Introdução dos editores convidados: TDD - A arte da programação sem medo [ link ]

Todos os pesquisadores parecem concordar que o TDD incentiva um melhor foco na tarefa e cobertura de teste. O simples fato de mais testes não significa necessariamente que a qualidade do software será melhor, mas a atenção aumentada do programador ao design de testes é, no entanto, encorajadora. Se considerarmos o teste uma amostra de uma população muito grande de comportamentos em potencial, mais testes significam uma amostra mais completa. Na medida em que cada teste pode encontrar um problema importante que nenhum dos outros pode encontrar, os testes são úteis, especialmente se você puder executá-los de maneira barata.

Tabela 1. Um resumo dos estudos empíricos selecionados do desenvolvimento orientado a testes: participantes do setor *

Tabela 2. Um resumo dos estudos empíricos selecionados de TDD: participantes acadêmicos *

Os efeitos do desenvolvimento orientado a testes na qualidade e produtividade externas: uma meta-análise [ link ]

Resumo:

Este artigo fornece uma metanálise sistemática de 27 estudos que investigam o impacto do desenvolvimento orientado a testes (TDD) na qualidade e produtividade de códigos externos.

Os resultados indicam que, em geral, o TDD tem um pequeno efeito positivo na qualidade, mas pouco ou nenhum efeito discernível na produtividade. No entanto, a análise de subgrupos constatou que tanto a melhoria da qualidade quanto a queda de produtividade são muito maiores nos estudos industriais em comparação aos estudos acadêmicos. Uma queda maior de produtividade foi encontrada em estudos em que a diferença no esforço de teste entre o TDD e o processo do grupo de controle foi significativa. Uma melhoria maior na qualidade também foi encontrada nos estudos acadêmicos quando a diferença no esforço de teste é substancial; no entanto, não foi possível concluir sobre os estudos industriais devido à falta de dados.

Finalmente, a influência da experiência do desenvolvedor e do tamanho da tarefa como variáveis ​​moderadoras foi investigada, e uma correlação positiva estatisticamente significativa foi encontrada entre o tamanho da tarefa e a magnitude da melhoria na qualidade.

Bem, existem algumas empresas grandes que exigem que você use o teste de unidade, mas se você é uma empresa pequena, por que imitar as grandes?

Para mim, quando comecei com o teste de unidade, há muitos anos (hoje em dia usamos principalmente o modelo de comportamento ), era porque eu não conseguia controlar todo o caminho em um aplicativo.

Eu estava acostumado com a primeira programação e um REPL, então, quando recebi o teste de unidade (um teste para cada função), foi como trazer de volta um REPL para idiomas que compilam muito. Ele trouxe a diversão de volta para todas as linhas de código que escrevi. Eu senti deus Eu gostei. Não precisava de um relatório para me dizer que comecei a escrever um código melhor mais rapidamente. Meu chefe não precisava de um relatório para perceber que, como estávamos fazendo coisas malucas, de repente nunca perdíamos um prazo. Meu chefe não precisava de um relatório para perceber que o número de bugs "comuns" cai de (para muitos) para quase nulo por causa dessa coisa muito estranha de escrever código improdutivo.

Como outro pôster já escreveu, você não usa o TDD para testar (verificar). Você o escreve para capturar a especificação, o comportamento do que sua unidade (objeto, módulo, função, classe, servidor, cluster) funciona.

Existem muitas falhas e histórias de sucesso na mudança para um modelo diferente de desenvolvimento de software em muitas empresas.

Comecei a usá-lo sempre que tinha algo novo para escrever. Há um velho ditado que me parece um pouco difícil de traduzir para o inglês, mas:

Comece com algo tão simples que você não percebe que o faz. Ao treinar para uma maratona, comece caminhando 9 metros e corra 1 metro, repita.

Existem estatísticas que comprovam que a correção de um erro encontrado no teste de unidade / integração custa muitas vezes menos do que a correção quando está no sistema ativo (eles são baseados no monitoramento de milhares de projetos da vida real).

Edit : por exemplo, como apontado, o livro " Code Complete " relata esses estudos (parágrafo 20.3, "Relative Effectiveness of Quality Techniques"). Mas também há pesquisas privadas no campo da consultoria que comprovam isso.

Eu tenho um conjunto de pontos de dados para isso - de uma experiência que me vendeu em testes de unidade.

Muitas luas atrás, eu era recém-formado trabalhando em um grande projeto VB6 e tive a oportunidade de escrever um grande corpo de código de procedimento armazenado. Do subsistema que eu escrevia, ele compunha cerca de 1/4 de toda a base de código - cerca de 13.000 LOC em cerca de 50K.

Eu escrevi um conjunto de testes de unidade para os procedimentos armazenados, mas o código de interface do usuário do VB6 de teste de unidade não é realmente viável sem ferramentas como o Rational Robot; pelo menos não era naquela época.

As estatísticas do controle de qualidade da peça foram que cerca de 40 ou 50 defeitos foram gerados em todo o subsistema, dos quais dois se originaram dos procedimentos armazenados. Esse é um defeito por 6.500 linhas de código vs. 1 por 1.000-1.200 ou mais em toda a peça. Lembre-se também de que cerca de 2/3 do código VB6 era um código padrão para manipulação e registro de erros, idêntico em todos os procedimentos.

Sem muita movimentação manual, você pode atribuir pelo menos uma melhoria de ordem de magnitude nas taxas de defeitos ao teste de unidade.