Alguém tem métricas sobre a utilidade do teste formal Unit?

https://stackoverflow.com/questions/333922

22-07-2019
|

Pergunta

Alguém tem métricas sobre a utilidade do teste formal Unit? Eu vejo um monte de atenção a ser pago para ferramentas de teste de unidade e eu estava curioso por quê?

Eu parei o teste de unidade formal de mais de 5 ou 6 anos atrás, e o ganho líquido da produtividade parece bastante elevado. Eu parei de teste de unidade, porque eu notei que ele nunca pegou nada - muito menos qualquer coisa útil. O tipo de erros que unidade de teste detecta parecem ser evitáveis ??por não beber mais de 2 copos de vinho / cerveja por hora (ou 2 articulações por hora). Também -. Teste de unidade parece criar risco, permitindo que o desenvolvedor de pensar que há alguma salvaguarda para pegar seus erros

Eu faço teste para garantir que o código funciona como deveria, mas eu não uso qualquer ferramenta. I teste com base nas mudanças que estão sendo feitas. Minha taxa de erro de produção para o novo código é de aproximadamente zero. Minha taxa de erro para alterações no código é de cerca de 2-3 erros por trimestre. As medidas acima são baseados em 4 aplicações de produção que desenvolvo / apoio.

Solução

Aqui é um segmento que tem alguma pesquisa sobre a abordagem TDD Pesquisa sobre TDD

Existe evidência concreta do ROI de unidade testes?

Outras dicas

Eu reconheço a sua superioridade como ser humano e um codificador.

No entanto, eu sou um mero idiota, e sem Python unittest, eu estaria perdido.

Eu não posso refatorar sem testes de unidade, ele só leva muito pensamento.

eu mal posso código sem testes de unidade, é muito difícil ter certeza absoluta de que eu absolutamente compreender absolutamente todas as nuances.

I teste de unidade, porque eu sou um idiota. Desde que você não cometer erros, você claramente não precisa de teste de unidade. Eu vos saúdo.

Editar. Para mim, testes unitários não são sobre métricas ou custos. Eu não preciso de nenhum, experimentos clínicos randomizados para me mostrar o valor. Eu não pode funcionar sem eles. Na verdade, eu me recuso a trabalhar sem eles. Em uma veia similar, eu não funcionará sem um compilador, um editor de texto, ou controle de código fonte; Eu não funcionará sem exigências; Eu me recuso a programa sem fazer design de primeira.

Não vejo o teste de unidade como um substituto para o teste tradicional, mas sim como um passo extra para garantir a correção do código. Algumas áreas particulares onde eu encontrar a unidade de teste úteis são:

Quando refatoração / alterar o código existente. Os testes de unidade irá verificar que pelo menos os casos ainda funcionam como esperado. Os testes mais você tem, mais certeza de que pode ser que as alterações de código não quebrar o código existente.
Ao enviar relatórios de erros. Ter um teste de unidade que expõe um bug é uma ótima maneira de demonstrar o erro e saber quando ele foi corrigido.
um meio de projetar interfaces. Você tem algum código de teste para verificar as interfaces com.

Provavelmente alguns outros que eu já esquecido :-P

PS: Como você sabe que você não faça bugs? Eu não acho que eu introduzir erros no código de trabalho I, mas que certamente não faz assim. IMHO, é ingênuo pensar que o seu código é livre de erros.

(Em relação a testes de unidade, se você sabe o seu código pode conter bugs - e eu diria que a maioria código faz - você não iria querer usar todos os meios possíveis para pegá-los)

Aqui estão algumas Livro Branco sobre teste de unidade que pode ajudá-lo:

Mas, Martin Fowler colocá-lo, a evidência anedótica de apoio a testes de unidade e TDD é esmagadora, mas você não pode medir a produtividade.

O teste de unidade é bom porque você pode mudar uma parte e saber se em algum outro lugar que tenha modificado alguma coisa. Algumas pessoas são "no amor" com a Unidade de Teste e deve acalmar theirselve. Eu acredito na Unidade de Teste, mas as pessoas que tentam tudo secreta são tão perigosos de pessoas que não fazer teste de unidade.

Eu não tenho nenhum métricas para apontar, mas acho que o aumento da popularidade é porque o resto de nós já teve experiência que é o oposto de seu. :)

Com os testes de unidade, posso corrigir bugs no código de produção e instalar a nova versão dentro de uma hora o bug foi encontrado e posso ter certeza de que a nova versão não é pior do que o que tínhamos antes - porque os testes me dizer tão. Poderia ser melhor, no entanto.

Eles me dão uma marca d'água inferior abaixo do qual a qualidade do meu código nunca pode afundar. Eles permitem-me para acompanhar a foto maior e ter os testes encontrar os pequenos erros que tendem a fazer. Eles também permitem-me desenvolver em um estilo muito relaxado.

Desde que eu teste, que tendem a entregar a tempo, a minha qualidade de código melhorou muito eo resultado geralmente funciona como esperado. Além disso, eu sou muito mais rápido desde que eu posso cortar o que seria muito perigoso para tentar se eu não tivesse os testes.

Dito isso, eu também não têm quaisquer números concretos nem sei qualquer fonte, apesar do fato de que eu estou fazendo teste de unidade e TDD durante anos. Meu amor por testes é baseada em pura palavra de boca e experiência pessoal.

Descobri que testes unitários me ajuda quando adicionando novas funcionalidades. Neste cenário que eu usei para preocupação de que o que eu estava adicionando ia quebrar algo em alguma parte remota do aplicativo. Mas com testes de unidade apropriados eu sei ou não eu quebrei alguma coisa no momento em que executar os testes.

Aqui está uma interessante discussão sobre a utilidade de testes de unidade.

Se você não gosta de testes de unidade, um outro conceito que você pode querer olhar é programação por contrato . que basicamente afirma que, se forem respeitadas determinadas condições de entrada, em seguida, haverá uma saída garantida de acordo com o contrato.

Eu sou um gerente de desenvolvimento. Para a minha organização, criação e migração para nhibernate envolvidos alguns custos de instalação e adicionado em nosso tempo de desenvolvimento. Alguns dos desenvolvedores gostaram, alguns pensaram que era um desperdício de tempo.

Não houve uma mudança notável nas taxas de erro, mas talvez seja muito cedo para dizer.

Da minha perspectiva, eu acho que ajuda desenvolvedores junior que não têm certeza de seu trabalho, mas para os desenvolvedores seniores, parece-atrasá-los - é mais uma coisa para se manter atualizado. Eu não tenho certeza se vamos continuar a utilizar este, de volta revert aos nossos velhos caminhos (ad hoc teste de unidade), ou permitir que os desenvolvedores fazer uma escolha pessoal.

Existem várias ferramentas que medem a cobertura de código com testes de unidade. Eles são uma parte essencial em conjunto com o teste de unidade para garantir que o código não só é testado, mas completamente testada.

Tudo o resto é magia apenas pura;)

Se você quiser código de refatoração, por definição, você precisa de alguma maneira de dizer se as mudanças quebrou o código. Na falta de discernimento divino, acho que o teste de unidade é uma ferramenta boa bonita, mas ymmv.

Eu especificamente tinha um monte de ganho usando Test Driven Development (TDD) com C ++ em uma enorme aplicação de servidor monolítica.

Quando eu estou trabalhando em uma área de código, eu primeiro garantir que aquela área é coberta com testes antes de eu mudar ou escrever um novo código.

Neste caso de uso eu tenho enormes ganhos de produtividade.

Para criar e executar o meu teste:. 10 segundos
construir, executar e testar manualmente o servidor completo:. Min 5 minutos

Isso significa que eu sou capaz de interagir uma área de código muito rapidamente e só testar completamente quando eu preciso.

Além disso eu também têm utilizado o teste de integração que levam mais tempo para construir e executar, mas apenas exercer a parte específica de funcionalidade que eu estou interessado.

Eu tenho alguma simpatia para o que você está dizendo. A minha experiência é semelhante em que os meus novos bugs raramente são pegos de testes de unidade. Se em tudo, os testes de unidade são modificados depois foi encontrado o bug para garantir que ele não reaparecer.

Onde testes de unidade me ajudaram está no desenho das minhas aulas (Java). Tenho muitas vezes reformulado as classes para torná-los testável (remoção de singletons, por exemplo) que, penso eu, tem melhorado o design geral. Para mim, isso é motivo suficiente para usá-los.

Em minha experiência Unit Testing me ajudou com o material seguinte:

Agora eu posso dar todo o meu foco para o bloco de código / função / classe que eu estou escrevendo sem se preocupar com qualquer outra coisa, porque eu sei que se eu fizer algo estúpido ou causa um efeito colateral meus testes me dirá
posso refatorar coisas por saber que eu não estou quebrando coisas
Tenho certeza de que meu aplicativo está funcionando como esperado
Antes de um comunicado eu não verificar cada única funcionalidade manualmente para confirmar esse aplicativo ainda funciona,
eu tenho certeza que a minha candidatura é sempre estável em algum nível

No entanto, este é um pouco relacionado com mim desde que eu sou muito ruim sobre "gestão de material múltiplos de cada vez" e "se concentrar". Portanto Unit Testing funciona para mim e literalmente salvar meu dia tantas vezes, onde eu introduziu um novo recurso e quebrou algumas funcionalidades de idade.

Se isto não é o caso de você simplesmente não usá-lo. Se você ainda está tendo o mesmo resultado, desempenho e qualidade com a mesma quantidade de erros, então isso significa que você não precisa de testes de unidade. Ou você precisa revisar suas metodologias de teste de unidade.

P.S. Com base na sua taxa de erro e que você disse que você soar como um gênio de qualquer maneira (supondo que estes são grandes projetos de médio ou), então eu diria que não usam testes de unidade, parece que você está fazendo bem. Mas para o resto do mundo que não são gênio como eu recomendo vivamente teste de unidade, porque ele trabalhou para mim.

Não sei sobre você, mas eu verifiquei apenas em duas correções para duas coredumps criadas por mudanças no código existente que os meus testes unitários pego. E eu só tinha um problema de produção que teria sido pego por um teste de unidade se eu tivesse mais confiança em seus resultados (nossos UnitTests são um pouco mais em um lado funcional do que eu gostaria de admitir).

Parece-me que o teste de unidade formal com as ferramentas de teste populares é muito bonito como segurança do aeroporto EUA.

Ele fornece a ilusão de segurança
Não faz 'sentir' as pessoas de boa
É muito inconveniente (extremamente inconveniente se você tem a pele cor errada)
As pessoas vão com raiva onda seu punho para você, se você criticá-lo ...
Essas mesmas pessoas serão esquerda confuso quando seu processo falhar e eles vão saltar sobre a próxima banda vagão ...

Eu acho que as pessoas têm diferentes perspectivas sobre software. Na minha opinião, o software é um meio de ganhar dinheiro (espero, proporcionando aumento de receitas ou economizar dinheiro). Eu vi as mensagens para TDD que é o mais próximo que eu vejo como uma forma científica para responder à pergunta, mas a metodologia carece de rigor científico. Nenhum dos artigos especificado tinha uma linha de base ou método alternativo bastante contrastado.

Eu acho que, os fãs de teste de unidade formal, continuará a sentir-se seguro em suas maneiras. Vou continuar a escrever o meu especificação em um pedaço de papel e colocar na tigela aos pés de minha estátua de Santo António e dizer uma oração. Quem pode dizer qual caminho é mais eficaz, mas a minha maneira se sente bem ... Talvez eu vou escrever um livro branco sobre o assunto.

Lembre-se o aumento da popularidade de 70 e 80 cortes de cabelo e roupas ... que não funcionou tão bem para aqueles de nós que viveram naquelas décadas.

teste de unidade formal leva um trabalho considerável e esforço para manter. Eu acho que é preciso 20-50% do tempo que leva para realmente desenvolver o software. O que estou pedindo é para o preço conhecido da adição de 20-50% em cima de todos os esforços de desenvolvimento, é o notável ganho e / ou proveable.

Ao não fazer o teste de unidade formal, você está forçando o desenvolvedor para pensar nas coisas apropriadas para teste. O desenvolvedor tem mais a propriedade do produto.

Unidade Formal testar sons como suco de óleo de cobra ... todo mundo e seu irmão dizem que é bom, útil, legal, etc., mas não houve um estudo controlado randomizado para provar que ele realmente economiza tempo e dinheiro. Todas as respostas até agora são testemunhos subjetivos.

O que eu gostaria de saber é se há um gerente de software que pode demonstrar uma maior produtividade (ou mesmo maior qualidade) após a introdução de testes de unidade.

lol - o discurso jocoso por S. Lott é a maior resposta classificou ... Dado este fórum é anônima (pelo menos para mim), o seu respeito não é o que estou procurando. Eu me considero pouco acima de medíocre. Eu já trabalhei com desenvolvedores excepcionais ... esses caras geralmente não até mesmo fazer testes básicos de seu código - eles só sei que vai funcionar.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow