Quais são os principais fatores na escolha de um Mocking Framework?

Estou procurando começar com objetos em meus testes de unidade. Parece que existem toneladas de boas estruturas de zombaria por aí.

1. As diferentes estruturas têm diferentes públicos-alvo?
2. Que fatores devo considerar ao escolher qual estrutura é adequada para minha situação?

As diferentes estruturas têm diferentes públicos-alvo?

Sim. Algumas estruturas, como Microsoft Moles , TypeMock Isolator e JustMock , permitem que você possa zombar de qualquer coisa. Essas ferramentas de simulação geralmente são melhores para os desenvolvedores que desejam usá-las no código legado existente, pois pode não ser possível refatorá-lo para um design mais testável. *

Tradicionalmente, os projetos testáveis ​​significam que a base de código precisa fazer uso liberal de interfaces, classes abstratas, métodos virtuais, classes não seladas etc. Portanto, as estruturas de simulação tradicionais como Moq e RhinoMocks funcionam bem com o código desenvolvido usando Test Driven Development, Injection Dependency e outros conceitos. A propósito, eu recomendo o uso da Injeção de Dependência à medida que você ganha muito mais do que apenas código testável, mas também código mais sustentável.

Que fatores devo considerar ao escolher qual estrutura é adequada para minha situação?

• Atividade de desenvolvimento. Ferramentas como Moq e RhinoMocks são muito ativas e populares e, portanto, atualizadas.
• Vs de código aberto. Comercial . Considere os vários prós e contras típicos dessa comparação. Custo, Suporte, etc ...
• Maturidade. Quão nova é a ferramenta. Está na versão beta (como o Microsoft Moles) ou teve vários lançamentos estáveis? Por exemplo, eu gosto de Moles para código legado, mas existem vários erros que precisam ser corrigidos e haverá uma espera antes que eles sejam resolvidos (próxima versão, novembro de 2011).
• Documentação. Existem vários livros e blogs que cobrem testes de unidade, zombaria, zombaria automática etc. Além disso, qual é a documentação da ferramenta?
• Sintaxe . Cada ferramenta tem sua própria maneira de dizer a mesma coisa. Veja qual é o melhor para você.
• Velocidade . As ferramentas que usam a criação de perfil CLR (TypeMock, Moles, JustMock) podem ser muito mais lentas que as tradicionais (Moq, RhinoMocks). Essa penalidade de velocidade pode ser um problema, pois você realiza muitos testes de unidade. A regra geral é que, se um teste demorar mais de 1/10 por segundo, é muito lento.
• Suporte da comunidade . Outros desenvolvedores estão escrevendo outras ferramentas que se estendem (ou funcionam como complemento) à ferramenta de simulação? Há um projeto Moq.Contrib que adiciona uma capacidade de zombaria automática ao Moq (que ajuda a acelerar o tempo de gravação do teste). Melhor ainda, há o AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, que também permite a simulação automática, além da criação de variáveis ​​anônimas.

^{* Consulte Trabalhando efetivamente com o código herdado , para obter maneiras de refatorar lentamente o código sem testes para o código que pode ser usado com as ferramentas tradicionais de teste (e zombaria).}

O tutorial do Moq tem uma seção sobre plano de fundo, filosofia e controvérsia logo no início, que discute isso em relação a algumas ferramentas específicas: TypeMock Isolator, RhinoMocks e Moq. Ele foi escrito para explicar o Moq, portanto é naturalmente um pouco distorcido, mas achei bastante útil para mim ao tentar entender algumas das diferenças nas estruturas de simulação.

Eu também achei úteis as respostas a esse thread SO no C # Mocking Frameworks . A maioria se refere apenas a uma Mocking Framework que o usuário realmente considera útil, mas há uma resposta do HaraldV que descreve maneiras de simulação e de proxy.

Também pude encontrar um gráfico de comparação on-line. Observe que é de 2009, então não tenho certeza se está atualizado; há pelo menos um comentário declarando que as informações sobre o TypeMock e os retornos de chamada estão desatualizadas, mas o gráfico pode ser bom para levantar questões a serem consideradas, mesmo que você precise fazer um trabalho braçal para ver qual é o estado atual: RhinoMocks, Moq, NMock, e gráfico de comparação TypeMock

Existe um projeto no Google Code com casos de teste em várias estruturas de simulação para fácil comparação de códigos: mocking-frameworks-compare

1. Fácil de usar. Algumas das estruturas têm expressões de uso mais avançadas. Por exemplo, o MOQ permite o uso de lambdas para codificar as expectativas. Algumas bibliotecas mais antigas não suportam isso.
2. Rapidez. Cada teste de unidade deve ser rápido, para que sua biblioteca inteira não demore horas para ser executada. Algumas estruturas de simulação têm simulações geradas estaticamente, o que é rápido. Outras estruturas geram código dinamicamente no tempo de execução, o que é mais lento.
3. Apoio, suporte. Você deseja uma estrutura que seja ativamente suportada com correções e atualizada para dar suporte a novas versões do .NET, conforme elas são lançadas.
4. Poder. A maioria das estruturas de zombaria que pesquisei são praticamente as mesmas em termos de poder. Há uma exceção notável. O Microsoft Moles permite zombar de "métodos não virtuais / estáticos em tipos fechados". Isso é algo que nenhuma outra estrutura de zombaria suporta, que eu saiba.

Na minha equipe, escolhemos o Microsoft Moles . Ele vence significativamente nos números 2, 3 e 4, embora seja menos idiomático do que a maioria das alternativas e está na extremidade inferior do número 1.