São estruturas simuladas e cobertura do teste elevado importante?

Question

quadros Mock, v.g. EasyMock, torná-lo mais fácil de plug-in manequim dependências. Dito isto, usando-os para assegurar como os diferentes métodos em componentes específicos são chamados (e em que ordem) parece ruim para mim. Ele expõe o comportamento a classe de teste, o que torna mais difícil manter o código de produção. E eu realmente não vejo o benefício; mentalmente eu me sinto como se eu estivesse acorrentado a uma bola pesada.

eu sou muito melhor como para teste apenas contra interface, dando dados de teste como entrada e afirmando o resultado. Melhor ainda, usar alguma ferramenta de teste que gera dados de teste automaticamente para a verificação determinada propriedade. por exemplo. adicionando um elemento a uma lista, e removê-lo imediatamente produz a mesma lista.

Em nosso local de trabalho, usamos Hudson que dá o teste de cobertura. Infelizmente, faz com que seja fácil de obter cegamente obcecado que tudo é testado. Eu sinto fortemente que não se deve testar tudo, se alguém quiser ser produtivo também no modo de manutenção. Um bom exemplo seria controladores em frameworks web. Como geralmente eles devem conter muito pouca lógica, testando com quadro simulado que o controlador chama o método tal e tal na ordem particular é absurda na minha opinião honesta.

Queridos Soers, quais são suas opiniões sobre isso?

Answer 1

Depende de como você modelar o domínio (s) do seu programa.

Se você modela os domínios em termos de dados armazenados em estruturas de dados e métodos que ler dados de uma estrutura de dados e armazenar derivada de dados em outra estrutura de dados (procedimentos ou funções dependendo como processual ou funcional seu projeto é), objetos então simulados não são adequadas. Assim chamado "estado baseada em" testes é o que você quer. O resultado que interessa é que um procedimento coloca os dados corretos nas variáveis ??certas e o que chama para que isso aconteça é apenas um detalhe de implementação.

Se você modelar os domínios em termos de protocolos de comunicação de transmissão de mensagens pela qual os objetos colaboram, em seguida, os protocolos são o que você se preocupa e que dados os objetos armazenar a coordenar o seu comportamento nos protocolos e nas quais desempenham papéis é apenas a implementação detalhe. Nesse caso, os objetos simulados são a ferramenta certa para o trabalho e Estado baseado testando os laços dos testes muito de perto para os detalhes de implementação sem importância.

E na maioria dos programas orientados a objetos há uma mistura de estilos. Algum código será escrito puramente funcional, transformando estruturas de dados imutáveis. Outro código será coordenar o comportamento dos objetos que mudam seu estado oculta, interna ao longo do tempo.

Quanto à cobertura de teste de alta, ele realmente não lhe dizer muito. baixa cobertura de teste mostra onde você tem testes inadequados, mas a cobertura de teste de alta não mostra que o código está adequadamente testado. Os testes podem, por exemplo, percorrer caminhos de código e assim aumentar as estatísticas de cobertura, mas não realmente fazer quaisquer afirmações sobre o que esses caminhos de código fez. Além disso, o que realmente importa é a forma como as diferentes partes do comportam programa em combinação, que a cobertura de teste de unidade não irá dizer-lhe. Se você quiser verificar se os testes realmente está testando o comportamento do seu sistema de forma adequada, você poderia usar uma ferramenta de Teste de Mutação. É um processo lento, por isso é algo que você executar em uma compilação de todas as noites em vez de em cada check-in.

Answer 2

Eu li 2 perguntas:

Qual é a sua opinião sobre o teste que os métodos específicos sobre os componentes são chamados em uma determinada ordem?

Eu caí em desgraça com isso no passado. Nós usamos muito mais "arrancar" e muito menos "zombando" estes dias. Tentamos escrever testes de unidade que testam apenas uma coisa. Quando fazemos isso, é normalmente possível escrever um teste muito simples Quais stubs de fora interacções com a maioria dos outros componentes. E nós ordenação muito raramente assert. Isso ajuda a tornar os testes menos frágil.

testes que testam apenas uma coisa são mais fáceis de entender e manter.

Além disso, se você se encontrar tendo que muitas gravação de expectativas para interações com lotes de componentes poderia haver um problema no código que você está testando qualquer maneira. Se é difícil para manter os testes o código que você está testando muitas vezes pode ser reformulado.

deve um ser obcecado com a cobertura do teste?

Ao escrever testes de unidade para uma determinada classe Eu estou muito obcecado com a cobertura do teste. Isso torna muito fácil de detectar partes importantes do comportamento que eu não testei. Eu também posso fazer um julgamento sobre quais as partes que não precisa de cobertura.

estatísticas de cobertura de teste de unidade geral? Não particularmente interessado, desde que eles são ricos.

100% de cobertura de teste de unidade para um sistema inteiro? Não estou interessado em tudo.

Answer 3

Eu concordo - Eu sou a favor de se inclinando fortemente para a verificação do estado em vez de verificação de comportamento (uma interpretação frouxa de clássico TDD enquanto ainda estiver usando duplas de teste).

O livro A Arte da Unidade de Teste tem abundância de bons conselhos nestas áreas.

cobertura de teste de 100%, teste de GUI, getters Testing / setters ou outro código não-lógica, etc. parecer improvável para prestar um bom ROI. TDD irá fornecer cobertura de teste alto em qualquer caso. Teste o que poderia quebrar.

Answer 4

Eu tinha uma pergunta semelhante Quanto Unit Testing é um coisa boa , o que poderia ajudar a dar uma idéia da variedade de níveis de testar as pessoas sentem são adequadas.

Answer 5

1. Qual é a probabilidade de que durante a manutenção de seu código algum funcionário júnior vai quebrar a parte do código que é executado "controlador chama o método tal e tal na ordem particular"?

2. Qual é o custo para a sua organização se tal coisa ocorre - em queda de produção, depuração / fixação / re-teste / re-lançamento, o risco jurídico / financeiro, risco de reputação, etc ...

Agora, multiplique # 1 e # 2 e verifique se o seu relutância para conseguir uma quantidade razoável de cobertura de teste vale a pena o risco.

Às vezes, não vai ser (é por isso que em testes há um conceito de um ponto de retornos decrescentes).

por exemplo. se você manter uma aplicação web que não é produção crítica e tem 100 usuários que têm uma solução alternativa se o aplicativo está quebrado (e / ou pode fazer fácil e reversão imediata), depois de passar 3 meses fazendo a cobertura de teste completo desse aplicativo é provavelmente não -sensical.

Se você trabalha em um aplicativo onde um menor erro pode ter vários milhões de dólares ou piores consequências (pense software do ônibus espacial, ou sistema de orientação para um míssil de cruzeiro), então o teste completo com a cobertura completa se torna muito mais sensical .

Além disso, eu não tenho certeza se eu estou lendo muito para sua pergunta, mas você parece estar dando a entender que ter unidade permitiu-zombeteiro testando alguma forma de aplicação excluds / testes funcionais de integração. Se for esse o caso, você está certo de se opor a tal noção - os dois testes aproxima co-existir obrigação

.