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

15

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

  1. Os diferentes frameworks têm diferentes públicos-alvo?
  2. Que fatores devo considerar ao escolher qual estrutura é adequada para minha situação?
por epotter 01.07.2011 / 17:41
fonte

3 respostas

14

Os diferentes frameworks têm diferentes públicos-alvo?

Sim. Alguns frameworks como Moles da Microsoft, TypeMock Isolator e JustMock , permite que você seja capaz de zombar de qualquer coisa. Em geral, essas ferramentas de simulação são melhores para os desenvolvedores que desejam usá-las no código legado existente, já que pode não ser possível refatorar um design mais testável. *

Tradicionalmente, projetos testáveis significam que o codebase precisa fazer uso liberal de interfaces, classes abstratas, métodos virtuais, classes não seladas, etc. Portanto, estruturas tradicionais de simulação como Moq e RhinoMocks funcionam bem com código desenvolvido usando Test Driven Development, Dependency Injection e outros conceitos. A propósito, eu recomendo usar a Injeção de Dependência, pois você ganha muito mais do que apenas código testável, mas também um 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, estão atualizadas.
  • Open Source vs. Comercial . Considere os vários prós e contras típicos dessa comparação. Custo, suporte, etc ...
  • Maturidade. Como é nova a ferramenta. Está em beta (como o Microsoft Moles) ou teve várias versões estáveis? Por exemplo, eu gosto de Moles para código legado, mas há vários bugs que precisam ser abordados nele e haverá espera antes de serem resolvidos (próximo lançamento em novembro de 2011).
  • Documentação. Existem vários livros e blogs que abrangem testes unitários, zombarias, auto-zombarias, etc. Além disso, quão boa é a documentação da própria ferramenta?
  • Sintaxe . Cada ferramenta tem sua própria maneira de dizer a mesma coisa. Veja qual é o melhor para você.
  • Velocidade . Ferramentas que usam o perfil CLR (TypeMock, Moles, JustMock) podem ser muito mais lentas que as tradicionais (Moq, RhinoMocks). Essa penalidade de velocidade pode ser um problema, já que você acumula muitos testes de unidade. A regra geral é 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 em elogio) à ferramenta de zombaria? Existe um projeto Moq.Contrib que adiciona uma habilidade Auto-mocking ao Moq (que ajuda a acelerar a escrita de testes Tempo). Melhor ainda, há AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, que também permite a auto-simulação, além de criação de variáveis anônimas.

* Veja Trabalhando efetivamente com o código herdado , para saber como refatorar o código lentamente sem testes em código que pode ser usado com ferramentas tradicionais de teste (e simulação).

    
por 01.07.2011 / 19:20
fonte
2

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 é escrito para explicar Moq, então é naturalmente um pouco distorcido, mas achei muito útil para mim quando tentei entender algumas das diferenças em estruturas de zombaria.

Eu encontrei as respostas para este segmento SO em C # Mocking Frameworks também útil. A maioria se refere apenas a um Mocking Framework que o usuário realmente acha útil, mas existe uma resposta de HaraldV , uma abordagem que discute zombarias baseadas em proxy e zombarias baseadas em profiler.

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

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

    
por 01.07.2011 / 18:47
fonte
2
  1. Facilidade de uso. Algumas das estruturas têm idiomas mais avançados de uso. Por exemplo, o MOQ permite o uso de lambdas para codificar as expectativas. Algumas bibliotecas antigas não suportam isso.
  2. Velocidade. Cada teste de unidade deve ser rápido para que sua biblioteca inteira não leve horas para ser executada. Alguns frameworks de zombaria geraram estaticamente, o que é rápido. Outras estruturas geram dinamicamente o código no tempo de execução, que é mais lento.
  3. Suporte. Você deseja uma estrutura que seja ativamente suportada com correções e atualizada para suportar novas versões do .NET, conforme forem liberadas.
  4. Potência. A maioria das estruturas de zombaria que eu pesquisei são aproximadamente as mesmas em termos de poder. Existe uma exceção notável. O Microsoft Moles permite zombar de "métodos não virtuais / estáticos em tipos selados". Isso é algo que nenhum outro framework de simulação suporta, que eu saiba.

Em minha equipe, escolhemos Microsoft Moles . Ele ganha significativamente em # 2, # 3 e # 4, embora seja menos idiomático do que a maioria das alternativas e esteja no nível mais baixo em # 1.

    
por 01.07.2011 / 18:52
fonte

Tags