Se o teste de unidade é tão bom, por que mais empresas não estão fazendo isso? [fechadas]

A primeira empresa de software real em que trabalhei era toda sobre testes de unidade (NUnit). Não sei se éramos realmente defensores disso naquela época - não tenho ideia de como era nossa cobertura de código e estava escrevendo a maioria dos testes de unidade. Desde então, encontrei algumas empresas que fazem muitos testes, mas são testes de cadeira: depende da presença de uma pessoa, tem baixa repetibilidade e baixa chance de detectar bugs. A outra atitude é: era algo que eles queriam fazer "no futuro"; basicamente quando o dinheiro cai do céu.

Sinto falta dos testes de unidade - eles apenas tornam a vida mais fácil. Mas estou descobrindo que, quando procuro um novo emprego, o teste de unidade é algo que as empresas gostariam de "fazer" no futuro ou algo que elas não fazem de jeito nenhum (uhh, já existe há um tempo agora!). Eu diria que 60-75% das solicitações de trabalho que examinei nos últimos 2 anos não listaram nenhum teste de unidade. Só consigo pensar em um ou dois que tiveram experiência em testes de unidade como um requisito (para uma posição de desenvolvedor de nível médio).

Portanto, a questão é: o que está faltando ? Acho que torna as pessoas mais produtivas, mas isso só depois de passar uma boa quantidade de tempo realmente fazendo isso. Não existem bons estudos sobre a economia de custos dos testes de unidade? É o tipo de empresa que estou procurando?

Edit: embora o título seja um pouco defensor do demônio, me considero um proponente de testes de unidade.

Na minha experiência, existem alguns fatores envolvidos nisso:

1. A gerência realmente não entende o que o teste de unidade realmente é, ou por que ele tem um valor intrínseco real para eles.
2. A gerência tende a se preocupar mais com a entrega rápida do produto e (incorretamente) vê o teste de unidade como contraproducente para esse objetivo.
3. Há uma percepção equivocada de que o teste pertence apenas ao controle de qualidade. Os desenvolvedores são programadores e não podem escrever testes.
4. Existe um equívoco comum de que a gerência terá que gastar dinheiro para fazer testes de unidade corretamente, apesar do fato de que as ferramentas estão disponíveis gratuitamente. (Há, é claro, o tempo de aceleração do desenvolvedor a ser considerado, mas não é realmente proibitivo.)
5. A resposta de Will completará esta resposta: É muito difícil determinar o valor do código de teste (editar jcollum)

Naturalmente, existem outros fatores, mas esses são exatamente os que encontrei até agora.

1) É difícil
2) Leva tempo
3) É muito difícil determinar o valor do código de teste

O ponto 3 é pegajoso. Bons testes de unidade reduzem os bugs. Mas o mesmo acontece com um bom código de produção. Como você determina quantos bugs não existem por causa de seus testes de unidade? Você não pode medir o que não existe. Você pode apontar estudos, mas eles não se encaixam bem na planilha do seu gerente de negócios.

É fácil colocar toda a culpa na "gestão". Mas a gerência está realmente dizendo para você especificamente não fazer nenhum teste de unidade?

O gerenciamento em geral não diz (e provavelmente não deveria) dizer a você como fazer seu trabalho, seja modularização, tipos de dados abstratos, padrões de projeto ou testes de unidade. Essas são ferramentas comerciais que um engenheiro de software competente e bem-sucedido aplica, mas um engenheiro pobre não.

Acho que a verdadeira resposta à sua pergunta é: o teste de unidade é realmente difícil e os alunos de ciência da computação não são treinados para isso.

É fácil quando você está escrevendo sua própria classe de string. Quando você está testando um produto da vida real, você se depara com desafios sobre os quais ninguém lhe falou nos slides do PowerPoint:

• Interação com o usuário. Metade do seu aplicativo é a lógica da interface do usuário. Como você testa de forma automatizada, que não quebra se você mover um botão?
• Interação com APIs e frameworks externos. Se você estiver escrevendo um driver de kernel do Windows, como fará o teste de unidade? Você escreve stubs para cada IRP e função do kernel que usa, criando efetivamente uma simulação do kernel do sistema operacional?
• As comunicações em rede são a moda do século 21. Como você coordena um teste de unidade que consiste em vários componentes distribuídos?
• Como você escolhe bons casos de teste? Costumo ver pessoas tentando a abordagem “fazer coisas aleatórias em um loop de 1000 iterações e ver se quebra”. Quando você faz isso, o esforço é maior do que o retorno, erros importantes são perdidos e o teste de unidade é abandonado.
• Como você testa se os requisitos de desempenho são atendidos?
• O conhecimento dos padrões de teste é escasso: stubs, respostas prontas, teste de regressão são conceitos que a maioria das pessoas não conhece. Quantas pessoas em seu local de trabalho realmente leram um livro sobre testes de unidade?

A única coisa pela qual podemos culpar o gerenciamento é que as especificações de requisitos raramente contêm quaisquer requisitos no nível de qualidade da entrega.

Na próxima vez que seu chefe pedir que você faça uma estimativa de tempo, inclua o tempo para escrever um teste de unidade e veja o que acontece.

A maioria dos testes não testa nada.
Você escreve uma função fileopen () e um unittest que falha se o arquivo não existir e é bem-sucedido se o arquivo existir. Ótimo! Você verificou se funciona com o nome do arquivo em chinês BIG5? em um compartilhamento NFS? no Vista com o arquivo em uma chave USB e UAC ligado?

O problema é que os testes de unidade são escritos pelo mesmo programador que escreveu a função, para o mesmo conjunto de suposições e com o mesmo nível de habilidade. Para realmente funcionar, os testes devem ser escritos por outra pessoa, apenas de acordo com as especificações publicadas, sem que eles vejam o código. - Na maioria das empresas, apenas obter especificações escritas seria um grande avanço!

Os testes de unidade verificam se há erros no código de funções individuais. Eles podem funcionar para camadas de acesso a dados, bibliotecas matemáticas, etc, onde as entradas / saídas são bem conhecidas e a estrutura interna é complexa, mas para muitos casos, eles são apenas uma perda de tempo.
Eles falham quando os erros são devido a interações entre diferentes partes do código ou com o sistema operacional e o usuário. Problemas como configurações de DPI alto / baixo bagunçando uma caixa de diálogo ou uma configuração de idioma estrangeiro trocando um '.' e ',' geralmente não são encontrados.

Foram feitos estudos sobre o ROI dos testes de unidade - veja esta pergunta .

Eu encontrei muitos desenvolvedores que não estão interessados ​​em testes de unidade. Sempre parece ser muito trabalhoso, com pouca recompensa quando você começa. Ninguém quer se inscrever para um trabalho extra e por isso resistem. Uma vez que as pessoas começam, elas geralmente se apegam a ele com entusiasmo, mas pode ser difícil começar.

Além da questão da adoção do teste de unidade, o teste de unidade nem sempre vale a pena, embora em geral eu pense que sim, quando aplicado corretamente. Não há nada de especial nos testes de unidade que os evite de serem vulneráveis ​​a construções ruins.

Os testes de unidade têm custos (criação, manutenção e execução) e só valem a pena se fornecerem benefícios maiores do que esses custos. A criação de testes é uma habilidade como qualquer outra, requer experiência e conhecimento específicos para o sucesso. Sem experiência suficiente, é muito fácil, mesmo para desenvolvedores experientes, criar testes de unidade de baixa qualidade, baixo valor e / ou alto custo que não valem a pena. Especialmente considerando o quão difícil pode ser julgar o valor de um teste de unidade.

Além disso, o teste de unidade é apenas uma maneira de melhorar a qualidade do código, mas não é a única maneira. Em algumas circunstâncias e com algumas equipes, pode não ser a maneira mais eficaz de aumentar a qualidade do software.

Lembre-se de que colocar muito esforço em testes de unidade não é garantia de software de qualidade. E, também, é possível produzir software da mais alta qualidade sem qualquer tipo de teste de unidade.

Bem, minha empresa não adotou TDD ou Testes Unitários. Para ser honesto, não temos certeza de como fazer isso. Obviamente, podemos fazer isso para funções estúpidas como CapitalizeString (), etc, mas não sabemos como fazer para sistemas altamente complexos com objetos complicados. Além disso, a maioria das pessoas entrevistadas tem experiência zero ou experiência limitada. Parece que o Teste de Unidade é grande na multidão do SO, mas não é particularmente grande no pool de trabalho disponível.

TDD é um tópico separado. Somos moralmente contra o TDD. Não somos programadores cowboy, mas acreditamos que isso prejudica a criatividade e a flexibilidade de um projeto. Além disso, não faz sentido ter o codificador que escreveu a função de teste de unidade. Quando eu faço algo, eu codifico para todos os casos extremos que posso pensar. O que preciso é de outro cérebro para procurar coisas que posso ter perdido. Nós não temos isso. As equipes são pequenas e independentes.

Resumindo, não acreditamos em TDD, mas gostaríamos de fazer o Teste Unitário. Simplesmente não temos experiência para fazer isso e não podemos encontrar isso facilmente.

Existem muitas empresas por aí que realmente não fazem nada em relação às melhores práticas. Sem revisões de código, sem testes de unidade, sem planos de teste, sem nada, apenas pelo assento de suas calças.

Aproveite esta oportunidade para levá-los a usar uma plataforma de Integração Contínua e desenvolver testes de unidade! Uma maneira fácil de impressionar os poderosos e aumentar a qualidade e estabilidade do seu código ao mesmo tempo

Edit: Quanto à razão, acho que eles simplesmente não estão cientes das ferramentas atuais que tornam o CI e os testes de unidade extraordinariamente fáceis.

Pelo que tenho visto, muitas empresas têm bases de código enormes e altamente acopladas que não são praticamente testáveis ​​por unidade. Eles também não têm requisitos testáveis ​​decentes, portanto, os testes de unidade seriam testados em relação aos requisitos de fato "conforme construído".

Não acho que preguiça seja a causa raiz de testes de unidade ruins. Para minha empresa, as limitações de tempo e a atitude de "basta fazer" são os maiores impedimentos para fazer testes de unidade. Além disso, os locais onde nossos sistemas falham tendem a ser mais no nível de integração (serviços, acessos ao banco de dados, consultas complexas que requerem dados específicos para teste), não no "nível da unidade". Essas coisas são apenas mais difíceis de testar e, se você mal tiver tempo para concluir o recurso, provavelmente não terá tempo para fazer nenhum teste útil ao mesmo tempo.

O teste de unidade deve ser apenas uma parte natural do fluxo de trabalho de desenvolvimento de código, assim como o compilador.

No entanto, isso requer educar o gerenciamento sobre os benefícios dos testes de unidade. No entanto, os desenvolvedores juniores têm chances relativamente baixas de exercer tal influência. Portanto, se uma empresa é uma proponente do teste de unidade depende se ela tem um desenvolvedor sênior ou arquiteto que defende o teste de unidade.

Acredito que esta seja a resposta à sua pergunta "o que está faltando e por que não há mais empresas fazendo testes de unidade" . :-)

Provavelmente é uma combinação de algumas coisas que você já mencionou. É difícil medir as economias de custo de TDD. Se você deseja terceirizar sua TI, pode mostrar quanto você paga por ano para os funcionários que você tem em comparação com o custo de terceirizar; é muito concreto. Como você diz, "Oh, este teste detectou um bug que levaria 4 horas para depurar e corrigir ..."?

O motivo pelo qual alguns lugares não o usam é simplesmente porque é preciso muito trabalho para começar e continuar. O fato de escrever testes de unidade levar tanto tempo quanto escrever a funcionalidade real parece para alguns gerentes que você está cortando a produtividade do desenvolvedor pela metade.

Além disso, você constrói uma equipe (ou alguém) precisa colocar a infraestrutura no lugar e mantê-la.

E, como diz Alan , muitos lugares simplesmente não usam as melhores práticas - eles apenas querem ver algo tangível.

Acho que o programador precisa apenas começar a fazer isso. Alguns testes simples para começar são fáceis de justificar como parte do desenvolvimento.

Quase sempre é necessário algo como um teste de unidade para obter uma resposta rápida de depuração. Apenas explique como é muito mais rápido iniciar o teste do que organizar a entrada correta, definir um ponto de interrupção do depurador, iniciar o aplicativo, etc.

Documente o teste em seu código. Basta colocar um comentário explicando onde está o teste e como executá-lo. Os futuros programadores verão isso e, com sorte, os testes se espalharão!

Teste de unidade é um daqueles termos da caixa preta que a maioria das pessoas já ouviu, mas não sabe exatamente o que constitui um teste de unidade, por onde começar, como escrevê-los, como realmente executar testes, o que exatamente eles deveriam testar, etc. . etc etc.

Em muitos casos, é mais fácil para o desenvolvedor inseguro simplesmente descartá-los como desnecessários ou alguma cobertura que apenas "desenvolvedores de nível corporativo" precisam.

Sou um grande fã de testes unitários e também sou sócio de uma empresa que desenvolve projetos de desenvolvimento de contratos para vários tipos de clientes. Em um mês, tocaremos de 3 a 4 projetos diferentes de tamanhos variados.

Se um projeto parece que vai ser único, não vou investir muito em testes de unidade porque esse teste de unidade não compensa para o meu negócio. Nesses tipos de projetos, irei testar a unidade de coisas que não tenho certeza / com as quais estou familiarizado ou que podem mudar com frequência (como um analisador para uma fonte de dados que não controlo).

Por outro lado, se estou construindo algo que sei que terá um longo tempo de vida, é um trabalho maior, com o qual trabalharei por meio de várias iterações ou que terá um grande impacto em meus clientes se ocorrer um erro , Vou investir em mais testes de unidade. Mais uma vez, a prioridade dos testes gira em torno de código incerto / desconhecido / em mudança.

Acho que os testes de unidade devem girar em torno da complexidade de uma tarefa, bem como se eles vão valer a pena. Não faz sentido escrever código extra que não será usado.

Na minha experiência, realmente depende do software que você está escrevendo. Descobri que é extremamente difícil escrever testes de unidade para uma IU. Eu só uso testes de unidade para partes do sistema que têm uma entrada / saída definida.

Sinto falta dos testes de unidade - eles apenas tornam a vida mais fácil.

Isso não é , realmente, um motivo suficiente para uma empresa adotar o teste de unidade.

Uma razão suficiente pode ser "mais barata" (e / ou "melhor"): o que não é tão fácil de provar sobre o teste de unidade.

A única boa razão pode ser "escrever testes de unidade é o melhor uso do tempo dos desenvolvedores", o que é realmente difícil de provar IMO: e pode ser verdade em alguns lugares, para algum software, com alguns desenvolvedores, e não é verdade em outros lugares.

Existem muitos desenvolvedores que não pensam o mundo dos testes de unidade: incluindo alguns que pensam que outras formas de teste (por exemplo, integração automatizada / testes funcionais) podem ser mais baratas e valiosas, por exemplo, Eu sou o único desenvolvedor que não t gosta de testes de unidade?

Claro, no mundo ideal, você não pode argumentar contra ter um teste de unidade.

No entanto, se você escreve um teste de unidade depende de uma série de coisas:

• Como o software será usado. Se você estivesse escrevendo software apenas para você, escreveria testes de unidade? Provavelmente não. Se você estava escrevendo um software pré-empacotado para ser vendido comercialmente, provavelmente sim.

• Quantas pessoas mantêm o código ... se for apenas você, então você pode conhecê-lo bem o suficiente para estar confiante o suficiente, após fazer uma alteração, de que uma rápida execução do código é suficiente para garantir que nada foi quebrado. Se outras pessoas que não escreveram o código originalmente precisarem mantê-lo, um teste de unidade ajudará a dar-lhes confiança de que, quando atualizarem o código para corrigir um problema grande (que obviamente não foi capturado no teste de unidade!), Eles não quebraram nada .

• complexidade do código: teste apenas o código que precisa de um teste. Um método de atribuição de variável de uma linha não precisa de teste. Um método de 50 linhas com vários caminhos de execução provavelmente sim.

• Considerações comerciais práticas: o fato é que escrever testes de unidade leva mais tempo do que não fazê-lo. Se você está escrevendo um protótipo de software, que tem um futuro comercial incerto, então há uma recompensa a ter entre ter um código rápido, agora, que funcione suficientemente bem contra ter um código testado por unidade em 2 semanas que funcione melhor. Às vezes, vale a pena descobrir rapidamente (apetite do consumidor) se o software terá uma prateleira curta e passar para o próximo projeto.

e como outros apontaram, um teste é tão bom quanto a pessoa que o escreveu.

O principal motivo é que muitos desenvolvedores e gerentes de desenvolvimento não têm ideia da existência de testes de unidade ou de como usá-los.

A segunda razão é que os testes de unidade só podem ser usados ​​(de maneira sensata) com código que já atenda a alguns padrões de qualidade. As chances são de que alguma base de código existente não se enquadre nessa categoria.

A terceira razão é preguiça e / ou baixo custo.

Porque os testes de unidade só são úteis se você escrever código testável. E escrever código testável é difícil. E as pessoas são preguiçosas e / ou baratas.

EDITAR: matizado "preguiçoso" como "preguiçoso e / ou barato"; em raras ocasiões, as pessoas realmente têm a habilidade, a capacidade e a vontade de escrever testes, mas têm outra coisa a fazer que afeta mais diretamente os resultados financeiros.

Acho que parte do problema é que os desenvolvedores esperam que os empresários tenham o mesmo conjunto de valores e realmente se preocupem com a resposta "devemos testar a unidade ou não?". Não obtemos aprovação prévia do negócio para usar uma linguagem de alto nível em vez da linguagem assembly - geralmente é a maneira sensata de fazer o trabalho.

A questão é que somos os únicos qualificados para fazer a chamada (o que não quer dizer que todos nós temos o mesmo conhecimento sobre o assunto). Além disso, mesmo que sua equipe não faça, por uma questão de política, testes de unidade (ou nomeie seu método do dia), geralmente não significa que você não possa fazê-lo.

A verdade é que não podemos realmente provar o ROI na maioria das coisas que fazemos com uma granularidade muito fina. Por que o teste de unidade é realizado de acordo com esse padrão de prova irracional / atípico está além da minha compreensão ...

As pessoas são preguiçosas e só adotam mudanças quando são forçadas.

Meus 2 centavos:

• Requer alguma educação e disciplina, mas os recém-formados já vêm com o conhecimento adequado.
• A sobrecarga de testes pode ser reduzida com ferramentas melhores e isso também está acontecendo (refatoração etc.)

Então, é só questão de tempo.

Há o debate Martin-Coplien em que Bob Martin afirma que:

"hoje em dia é irresponsável um desenvolvedor lançar uma linha de código que ele não executou em um teste de unidade."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Se você quiser convencer todos sobre o teste, faça o seguinte:

1. Escreva um monte de testes.
2. Notifique os outros desenvolvedores que alterarem o código e falharem no (s) teste (s).
3. Eles vão consertar seu código.
4. Agora você pode lançar sem esses bugs específicos.

Até mesmo um gerente poderia entender isso.

As empresas não estão realizando testes de unidade, pelo mesmo motivo que muitos sites são mal escritos - ignorância e pessoas aderindo a velhos hábitos. Na minha empresa, desde que começamos os testes de unidade (com Nunit e Typemock ), alcançamos maior cobertura de código e lançamos o software em um tempo menor para o mercado.

Como a maioria das boas ideias, a adoção tem mais a ver com a dependência do caminho organizacional do que com a qualidade da ideia.

Na maioria das empresas que enviam produtos, uma divisão de QA substancial foi criada com um chefe de QA de nível sênior. O teste é o feudo da equipe de QA.

É improvável que a equipe de QA escreva o código de teste de unidade porque a empresa normalmente não compõe a equipe de QA com seus codificadores de serviço pesado.

A equipe de programação reluta em escrever o código de teste porque isso cria um conflito com a equipe de QA.

Tenho visto mais interesse e adoção de testes de unidade em grupos onde o controle de qualidade não foi dividido em uma função de trabalho separada

Simples, custa dinheiro escrever e atualizar testes de unidade. A maioria dos softwares anteriores das empresas não tem testes de unidade e custará muito para escrever. Então, eles não fazem isso e isso aumenta o tempo do processo de desenvolvimento, então eles também não o adicionam a novos recursos.

A maioria das empresas é inútil. Não aquele para o qual você (ou eu) trabalhamos, obviamente.