Padrões para objetos simulados

Question

No livro de Roy Osherove [Teste de unidade] [1] livro, ele explica que um único teste de unidade deve conter entre 0 e 1 zombarias. Ele sugere que, se o seu teste não estiver afirmando a simulação, não use uma simulação. Ele demonstra ainda como usar uma estrutura de isolamento para produzir stubs, que foram criados de maneira semelhante às zombarias. Ele não coloca nenhum limite sugerido para o número de stubs criados por teste.

Minha pergunta é a seguinte: essas recomendações podem ser aplicadas a todas as estruturas de isolamento (ou todas as estruturas C# populares)? Em outras palavras, existe uma estrutura que pode gerar apenas zombares - não stubs? Existe uma estrutura de isolamento que não distingue zombarias dos stubs?

Só estou curioso para saber como as recomendações fáceis de Osherove podem ser convertidas em padrões de codificação.

[1]: http: // O sistema em teste não está sendo testado, em vez disso, os dados retornados de zombares são o que está sendo testado.

Answer 1

Existem estruturas como o MOQ que não as distinguem. O FakeTeasy vai ainda mais longe e chama tudo de objetos falsos.

Sim, eles podem ser aplicados, porque as manchas são apenas mais espertos. Não importa muito se Stub for chamado como simulado, desde que você não afirme mais de uma simulação. Essa recomendação, em outras palavras, é mais sobre afirmar apenas uma coisa por teste. Distinguir explicitamente zombarias e stubs não é tão importante.

Answer 2

Isso corresponde diretamente à recomendação da OSHEROVE de que você execute apenas uma afirmação por teste. Em seu léxico um stub é uma classe que fornece informações falsas para o sistema em teste, enquanto um mock é uma classe que permite testar a saída do sistema em teste (usando uma classe falsa).

Se uma estrutura usa uma convenção de nomenclatura semelhante depende de seus designers, mas o padrão (se você concorda com a recomendação dele) deve ser que apenas um afirme seja realizado por teste e onde a afirmação requer um objeto falso - que apenas um objeto falso deve ser testado por teste.

Obviamente, nem todos concordam com sua recomendação, então nem todos fazem isso dessa maneira.

Answer 3

Philip Calçado escreveu recentemente sobre isso: http://fragmental.tw/2010/12/14/one-mock-per-test-considered-not-awesome/. Em suma, ele diz que focar em quantas zombarias/stubs existem em seus testes desviam você do que deve ser a principal preocupação: escrever boas especificações.

Answer 4

> can those recommendations 
> [a single unit test should contain between 0 and 1 mocks] 
> be applied to all isolation frameworks ?

Eu acho: na maioria das vezes Sim Se você assumir essas definições

• Unittest = teste isoladamente (caso contrário, não é o mais unitter)
• Um mais unitter para um recurso
• Um stub ou falso é um objeto para permitir o isolamento, mas isso não tem função de verificação e
• Uma simulação é um stub com funcionalidade extra que também permite a verificação

Answer 5

eu uso MoqPara minha zombaria Venha aqui

Não tenho certeza do que exatamente você quer dizer com "Stubbing", mas presumo que provavelmente seja algo como Moles from Microsoft O que é bem legal. Aqui

Ambos são realmente interessantes e muito fáceis de usar.

Answer 6

Esse tipo de regra deve ser visto como "rodas de treinamento". Obviamente, um teste que inclui muitos stubs e maquetes perdeu a trama, mas insistir em uma afirmação ou expectativa por teste é muito restritiva. Como o link de Calçado referenciado aponta, o que importa é que existe um conceito por teste, o que pode envolver algumas afirmações ou expectativas para fazer o ponto. A última coisa que você deve fazer é aplicar esse padrão.

Mais uma coisa, realmente deveríamos estar falando sobre "expectativas" aqui, interações individuais, em vez de objetos simulados inteiros. Na prática, eles costumam ser iguais, mas isso obscurece os conceitos.

Answer 7

Eu uso rinoceronte Mock para meu teste em C#. Você pode gerar zombarias ou stubs com ele. Encorajo você a dar uma olhada nessa estrutura: http://www.ayende.com/projects/rhino-mocks.aspx