¿Cuáles son los factores clave para elegir un marco de simulación?

Estoy buscando comenzar con los objetos en mis pruebas unitarias. Parece que hay toneladas de buenos marcos de burla por ahí.

1. ¿Los diferentes marcos tienen diferentes audiencias objetivo?
2. ¿Qué factores debo considerar al elegir qué marco es el adecuado para mi situación?

¿Los diferentes marcos tienen diferentes audiencias objetivo?

Si. Algunos marcos como Microsoft Moles , TypeMock Isolator y JustMock , le permiten poder burlarse de casi cualquier cosa. Estas herramientas de burla son generalmente mejores para los desarrolladores que desean usarlas en el código heredado existente, ya que es posible que no sea posible refactorizarlas en un diseño que sea más comprobable. *

Tradicionalmente, los diseños comprobables significan que la base de código necesita hacer un uso liberal de las interfaces, clases abstractas, métodos virtuales, clases no selladas , etc. Por lo tanto, los marcos de simulación tradicionales como Moq y RhinoMocks funcionan bien con el código desarrollado usando Test Driven Development, Dependency Injection y otros conceptos similares Por cierto, recomiendo encarecidamente usar la inyección de dependencia, ya que obtienes mucho más que un código comprobable, pero también un código más mantenible.

¿Qué factores debo considerar al elegir qué marco es el adecuado para mi situación?

• Actividad de desarrollo. Herramientas como Moq y RhinoMocks son muy activas y populares y, por lo tanto, están actualizadas.
• Código abierto vs. Comercial . Considere los diversos pros y contras típicos de esta comparación. Costo, soporte, etc.
• Madurez. Qué nueva es la herramienta. ¿Está en versión beta (como Microsoft Moles) o ha tenido varias versiones estables? Por ejemplo, me gustan los lunares para el código heredado, pero hay varios errores que deben abordarse y habrá que esperar mucho antes de que se solucionen (próximo lanzamiento, noviembre de 2011).
• Documentación. Hay varios libros y blogs que cubren pruebas unitarias, burlas, burlas automáticas, etc. Además, ¿qué tan buena es la documentación de la herramienta?
• Sintaxis . Cada herramienta tiene su propia forma de decir lo mismo. Vea cuál le queda mejor.
• Velocidad . Las herramientas que utilizan el perfil CLR (TypeMock, Moles, JustMock) pueden ser mucho más lentas que las tradicionales (Moq, RhinoMocks). Esta penalización de velocidad puede ser un problema a medida que acumula muchas pruebas unitarias. La regla general es que si una prueba lleva más de 1/10 por segundo, es demasiado lenta.
• Apoyo a la comunidad . ¿Están otros desarrolladores escribiendo otras herramientas que se extienden (o funcionan como complemento) a la herramienta de burla? Hay un proyecto Moq.Contrib que agrega una capacidad de burla automática a Moq (que ayuda a acelerar el tiempo de escritura de prueba). Mejor aún, hay AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, que también permite la burla automática, además de la creación de variables anónimas.

^{* Consulte Trabajar eficazmente con código heredado para obtener información sobre cómo refactorizar lentamente el código sin pruebas en el código que se puede usar con herramientas de prueba tradicionales (y simulacros).}

El tutorial de Moq tiene una sección sobre antecedentes, filosofía y controversia al principio que discute esto en relación con algunas herramientas específicas: TypeMock Isolator, RhinoMocks y Moq. Está escrito para explicar Moq, por lo que, naturalmente, está un poco sesgado, pero me pareció bastante útil cuando traté de comprender algunas de las diferencias en los marcos de burla.

Las respuestas a este hilo SO en C # Mocking Frameworks también me parecieron útiles. La mayoría solo se refiere a un Marco de Mocking que el usuario realmente encuentra útil, pero hay una respuesta de HaraldV que explica las simulaciones basadas en proxy y las simulaciones basadas en el generador de perfiles.

También pude encontrar una tabla de comparación en línea. Tenga en cuenta que es de 2009, por lo que no estoy seguro de que esté actualizado; hay al menos un comentario que indica que la información sobre TypeMock y las devoluciones de llamada están desactualizadas, pero el gráfico podría ser bueno para plantear problemas a considerar, incluso si necesita hacer un trabajo preliminar para ver cuál es el estado actual: RhinoMocks, Moq, NMock, y tabla de comparación TypeMock

Hay un proyecto en Google Code con casos de prueba en múltiples marcos de simulación para una fácil comparación de código: mocking-frameworks-compare

1. Facilidad de uso. Algunos de los marcos tienen modismos de uso más avanzados. Por ejemplo, MOQ permite el uso de lambdas para codificar expectativas. Algunas bibliotecas más antiguas no admiten esto.
2. Velocidad. Cada prueba unitaria debe ser rápida para que su biblioteca completa no tarde horas en ejecutarse. Algunos marcos de simulación tienen simulaciones generadas estáticamente, lo cual es rápido. Otros marcos generan dinámicamente código en tiempo de ejecución, que es más lento.
3. Apoyo. Desea un marco que sea compatible con correcciones y se actualice para admitir nuevas versiones de .NET, a medida que se publiquen.
4. Poder. La mayoría de los frameworks burlones que he investigado son más o menos los mismos en términos de poder. Hay una notable excepción. Microsoft Moles permite burlarse de "métodos no virtuales / estáticos en tipos sellados". Esto es algo que ningún otro marco burlón admite, que yo sepa.

En mi equipo, elegimos Microsoft Moles . Gana significativamente en # 2, # 3 y # 4, aunque es menos idiomático que la mayoría de las alternativas y está en el extremo inferior en el # 1.