O que não a prova quando se trata de Unit Testing?

https://stackoverflow.com/questions/109432

01-07-2019
|

Pergunta

Em quais partes de um escrever testes de unidade do projeto é quase ou realmente impossível? Acesso de dados? ftp?

Se houver uma resposta a esta pergunta, em seguida,% 100 cobertura é um mito, não é?

Solução

Aqui eu encontrei (via Haacked algo que Michael Feathers diz que pode ser uma resposta:

Ele diz:

Um teste não é um teste de unidade se:

Ele fala com o banco de dados

Ele se comunica através da rede

Toca o sistema de arquivos

Não podem ser executados ao mesmo tempo que qualquer outro de seus testes de unidade

Você tem que fazer coisas especiais para o seu ambiente (tais como a edição de arquivos de configuração) para executá-lo.

Novamente no mesmo artigo acrescenta:

De um modo geral, os testes de unidade é suposto ser pequeno, eles testar um método ou a interacção de um par de métodos. Quando você puxa o banco de dados, tomadas, ou o acesso ao sistema de arquivos em seus testes de unidade, eles não são realmente sobre esses métodos mais; eles estão prestes a integração de seu código com que outros softwares.

Outras dicas

Essa cobertura de 100% é um mito, que é, não significa que a cobertura de 80% é inútil. O objetivo, claro, é de 100%, e entre os testes unitários e testes de integração, em seguida, você pode abordá-lo.
O que é impossível em testes de unidade está prevendo todos os totalmente estranhas coisas seus clientes vão fazer para o produto. Uma vez que você começa a descobrir essas perversões incompreensível de seu código, certifique-se de testes de rolo para eles de volta para a suíte de testes.

alcançar a cobertura de código 100% é quase sempre um desperdício. Há muitos recursos sobre este assunto.

Nada é impossível para teste de unidade, mas há sempre retornos decrescentes. Pode não valer a pena para as coisas de teste de unidade que são dolorosas para teste de unidade.

O objetivo não é a cobertura de código 100% nem é a cobertura de código de 80%. Um teste de unidade sendo fácil escrever não significa que você deve escrevê-lo, e faz um testes de unidade sendo difícil escrever não significa que você deve evitar o esforço.

O objetivo de qualquer teste é detectar problemas visíveis usuário da maneira mais afforable.

é o custo total de criação, manutenção e diagnóstico de problemas sinalizados pelo teste (incluindo falsos positivos) vale a pena os problemas que as capturas de teste específico?

Se o problema das capturas de teste é 'caro', então você pode dar ao luxo de colocar esforço para descobrir como testá-lo, e manter esse teste. Se o problema das capturas de teste é trivial, em seguida, escrever (e manter!) O teste (mesmo na presença de alterações de código) melhor que seja trivial.

O objetivo principal de um teste de unidade é proteger devs de erros de implementação. Isso por si só deve indicar que muito esforço será um desperdício. Depois de um certo ponto há melhores estratégias para obter correcta aplicação. Também depois de um certo ponto os problemas do usuário visíveis são devido a correcta aplicação a coisa errada que só pode ser pego por nível de usuário ou testes de integração.

O que você não testar? Qualquer coisa que não poderia quebrar.

Quando se trata de cobertura de código que você quer para o objectivo de 100% do código que você realmente escrever - que é que você não precisa testar o código da biblioteca de terceiros, ou o código do sistema operacional desde que o código terá sido entregue a você testado. A menos que não o seu. Caso em que você pode querer testá-lo. Ou se há bugs conhecidos nesse caso, você pode querer testar para a presença dos erros, para que você obtenha uma notificação de quando eles são fixos.

O teste de unidade de um GUI também é difícil, embora não impossível, eu acho.

O acesso aos dados é possível porque você pode configurar um banco de dados de teste.

Geralmente as coisas 'não testável' é FTP, e-mail e assim por diante. No entanto, eles geralmente são classes do framework que você pode confiar e, portanto, não precisa de teste, se você escondê-los atrás de uma abstração.

Além disso, a cobertura de código 100% não é suficiente por si só.

@GarryShutler

Na verdade, eu unittest e-mail usando um servidor falso smtp (Wiser). Faz certeza de que o código do aplicativo está correto:

http: // maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/

Algo como isso provavelmente poderia ser feito por outros servidores. Caso contrário, você deve ser capaz de zombar do API ...

BTW: 100% de cobertura é apenas o começo ... significa apenas que todo o código tem realmente feijão executados uma vez .... nada sobre casos de ponta etc.

A maioria dos testes, que precisam enorme e caro (em custo de recurso ou computationtime) configurações são testes de integração. Os testes de unidade deve (em teoria), apenas testar pequenas unidades do código. As funções individuais.

Por exemplo, se você está testando e-mail funcionalidade, faz sentido, para criar um mock-mailer. O objetivo dessa simulação é certificar-se, o código chama o mailer corretamente. Para ver se o aplicativo envia realmente mail é um teste de integração.

É muito útil fazer uma distinção entre a unidade-testes e testes de integração. Unit-testes devem correr muito rápido. Deve ser facilmente possível executar todas as suas unidades-testes antes de verificar em seu código.

No entanto, se o seu test-suite é composta por muitos testes de integração (que configurar e derrubar bancos de dados e outros), o seu test-run pode facilmente exceder meia hora. Nesse caso, é muito provável que um desenvolvedor não será executado todas as unidades-testes antes que ela cheques em.

Assim, para responder à sua pergunta:. Fazer as coisas de teste de unidade de rede, que são melhor implementadas como um teste de integração (e também não testar getter / setter - é um desperdício de tempo ;-))

Em testes de unidade, você não deve testar qualquer coisa que não pertence a sua unidade; testando unidades em seu contexto é uma questão diferente. Essa é a resposta simples.

O uso básico regra que é que você deve unidade nada teste que toca os limites da sua unidade (geralmente de classe, ou qualquer outra coisa que a sua unidade poderia ser), e zombar o resto. Não há necessidade de testar os resultados que alguns de consulta de banco de dados retorna, basta teste que seus espetos unidade fora a consulta correta.

Isto não significa que você não deve omitir o material que é apenas difícil de teste; até mesmo manipulação de exceção e problemas de concorrência pode ser testado muito bem usando as ferramentas adequadas.

"O que não a prova quando se trata de Unidade de Teste?" * Feijão com getters apenas e setters. Raciocínio:. Normalmente, um desperdício de tempo que poderia ser melhor gasto testando outra coisa

Qualquer coisa que não é completamente determinista é um não-não para testes de unidade. Você quer que seus testes de unidade sempre passar ou não com as mesmas condições iniciais - se estranheza como threading, ou geração de dados aleatórios, ou o tempo / datas ou serviços externos podem afetar isso, então você não deveria estar cobrindo-o em seus testes de unidade . Time / datas são um caso particularmente desagradável. Você pode geralmente código arquiteto para ter uma data para trabalhar com ser injetado (por código e os testes) em vez de confiar na funcionalidade na data e hora atual.

Dito isto, porém, testes de unidade não deve ser o único nível de testar na sua aplicação. Alcançar a cobertura de teste da unidade 100% é muitas vezes um desperdício de tempo, e rapidamente encontra retornos decrescentes.

Muito melhor é ter um conjunto de testes funcionais de nível superior, e testes de integração até mesmo para garantir que o sistema funciona corretamente "uma vez que é tudo juntou-se" - que os testes de unidade, por definição, não teste.

Tudo o que precisa de uma configuração muito grande e complicado. Claro que você pode testar ftp (cliente), mas então você precisa configurar um servidor ftp. Para o teste de unidade que você precisa de uma configuração de teste reproduzível. Se você não pode fornecê-la, você não pode testá-lo.

Você pode testá-los, mas eles não serão testes de unidade. teste de unidade é algo que não atravessa as fronteiras, como a travessia sobre o fio, batendo banco de dados, executando / interagindo com um terceiro, Tocando um / legado testado base de código etc.

Qualquer coisa além disso é o teste de integração.

A resposta óbvia da pergunta do título é Você não deveria teste de unidade os internos de sua API, você não deve contar com o comportamento de outra pessoa, você não deve testar qualquer coisa que você não é responsável.

O resto deve ser suficiente apenas para torná-lo capaz de escrever seu código dentro dele, não mais, não menos.

Claro cobertura de 100% é uma boa objetivo quando se trabalha em um projeto grande, mas para a maioria dos projetos de fixação de um ou dois bugs antes da implantação não é necessariamente a pena o tempo para criar testes de unidade exaustivos.

exaustivamente testar coisas como envio de formulários, acesso a banco de dados, acesso FTP, etc em um nível muito detalhado muitas vezes é apenas uma perda de tempo; a menos que o software que está sendo escrito as necessidades de um nível muito elevado de confiabilidade (99,999% coisas) a unidade de teste em excesso pode ser um exagero e uma pia tempo real.

Não concordo com a resposta de quamrana respeito não testar código de terceiros. Este é um uso ideal de um teste de unidade. E se de erros (s) são introduzidas em uma nova versão de uma biblioteca? Idealmente, quando uma nova biblioteca versão de terceiros é liberado, você executar os testes de unidade que representam o comportamento esperado desta biblioteca para verificar se ele ainda funciona como esperado.

A configuração é outro item que é muito difícil de teste bem em testes de unidade. Testes de integração e outros testes devem ser feito contra configuração. Isso reduz a redundância de testes e libera uma grande quantidade de tempo. Tentando configuração de teste de unidade é muitas vezes frívola.

FTP, SMTP, E / S, em geral, deve ser testado utilizando uma interface. A interface deve ser implementada por um adaptador (para o código real) e um mock para o teste de unidade.

No teste de unidade deve exercer o recurso externo real (servidor FTP etc)

Se o código para configurar o estado necessário para um teste de unidade torna-se significativamente mais complexo do que o código a ser testado I tendem a desenhar a linha, e encontrar outra maneira de testar a funcionalidade. Nesse ponto você tem que perguntar como você sabe o teste de unidade é certo!

FTP, e-mail e assim por diante você pode testar com uma emulação de servidor. É difícil, mas possível.

Não testável são alguns manipulação de erro. Em cada código há manipulação de erro que nunca pode ocorrer. Por exemplo, em Java não devem ser pegar muitos exceção, porque é parte de um interface. Mas o exemplo usado nunca vai jogá-lo. Ou o caso padrão de um switch se para todos os casos possíveis de existir bloco caso.

É claro que alguns da manipulação de erro não necessária pode ser removido. Mas há um erro de codificação no futuro, então isso é ruim.

A principal razão para o código de teste de unidade, em primeiro lugar é para validar o design do seu código. É possível ganhar a cobertura de código 100%, mas não sem usar objetos fictícios ou alguma forma de injeção de isolamento ou dependência.

Lembre-se, testes unitários não são para usuários, eles são para desenvolvedores e sistemas de construção a ser usado para validar um sistema antes do lançamento. Para esse efeito, os testes de unidade deve executar muito rápido e ter tão pouco configuração e dependência fricção quanto possível. Tente fazer o máximo que puder na memória, e evitar o uso de conexões de rede a partir dos testes.

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

Não afiliado a StackOverflow