¿Cuáles son las diferencias entre simulacros y trozos en Rhino Mocks?

No he jugado lo suficiente con esto y generalmente uso simulacros, pero me pregunto cuáles son las diferencias entre estos dos y cuándo usar uno u otro en Rhino Mocks.

Actualizar:

También encontré la respuesta a mi pregunta en las palabras de Ayende :

La diferencia entre talones y simulacros

Puede obtener la definición real de estos términos en este artículo: Los simulacros no son talones . Quiero centrarme en la diferencia desde el punto de vista de Rhino Mocks.

Un simulacro es un objeto sobre el que podemos establecer expectativas, y que verificará que las acciones esperadas realmente hayan ocurrido. Un trozo es un objeto que utiliza para pasar al código que se está probando. Puede configurar expectativas en él, para que actúe de cierta manera, pero esas expectativas nunca se verificarán. Las propiedades de un código auxiliar se comportarán automáticamente como propiedades normales, y no puede establecer expectativas sobre ellas.

Si desea verificar el comportamiento del código bajo prueba, utilizará un simulacro con la expectativa adecuada y lo verificará. Si solo desea pasar un valor que puede necesitar actuar de cierta manera, pero no es el enfoque de esta prueba, utilizará un trozo.

IMPORTANTE: Un trozo nunca hará que una prueba falle.

Según esto

... En pocas palabras, hay una diferencia entre los objetos Mock y Stub y RhinoMocks reconoce que nos permite escribir pruebas que mejor expresan su propósito.

Los objetos simulados se usan para definir expectativas, es decir: en este escenario, espero que se llame al método A () con tales parámetros. Las simulaciones registran y verifican tales expectativas.

Los trozos, por otro lado, tienen un propósito diferente: no registran ni verifican las expectativas, sino que nos permiten "reemplazar" el comportamiento, el estado del objeto "falso" para utilizar un escenario de prueba ...

En términos generales, la Unidad prueba las funciones y métodos de llamada, y luego verifica si se produjo el comportamiento esperado. Estas funciones y métodos pueden requerir parámetros. Utilizamos trozos y simulacros para satisfacer estos parámetros. A veces también podemos burlarnos de los objetos globales.

Trozos

Un Stub es un pequeño objeto falso que su prueba puede usar como parámetro para hacer que la llamada a la función funcione. Esto nos permite verificar el comportamiento de la función bajo prueba. No nos permite verificar ningún efecto secundario, porque el código auxiliar no tiene implementación.

Simulacros

Un simulacro es un trozo con una implementación. Si nuestra función bajo prueba interactúa con nuestro objeto simulado, podemos verificar que se haya interactuado con el simulado como esperábamos.

Por ejemplo, supongamos que teníamos un objeto de usuario simulado y queríamos verificar que nuestro método session.login funcionara, es posible que queramos verificar que se haya configurado user.lastLoggedIn. Podríamos crear un usuario simulado que implemente este método. Cuando llamamos a session.login, podemos afirmar que user.lastLoggedIn tiene el estado que esperábamos.

Para resumir

Un simulacro es un trozo con una implementación, que nos permite probar los efectos secundarios.

¿Sigue siendo importante esta diferencia?

Al igual que la diferencia entre símiles y metáforas, la diferencia entre trozos y simulacros es sutil e histórica, y quizás tenga más que ver con las diferentes comunidades y filosofías en el mundo de las pruebas que cualquier diferencia técnica importante.

Representan enfoques ligeramente diferentes para las pruebas. Un simulacro se puede escribir como un trozo. Un trozo generalmente se puede expandir en un simulacro.

¿Cuál deberías usar?

Puede descubrir que comienza creando trozos, luego puede encontrar que necesita crear simulacros completos para algunos de sus objetos. Es posible que desee burlarse de todo a medida que avanza, o puede querer burlarse de donde sea necesario.

Diferencia entre Mock y stub: con stub, corrige la entrada de su prueba unitaria: por lo que su prueba unitaria no hace afirmaciones en stub y Stub al reescribir la implementación de algún método para corregir el comportamiento del objeto falso. con Mock, arreglas el resultado de la prueba de tu unidad: así que tu prueba de unidad hace una expectativa sobre tu objeto Mocking al verificar la interacción interna en tu objeto simulado.

En el caso del framework Moq, el método de configuración es STUB, mientras que el método Verify es Mock

Una cosa que también noté es que cuando uso MockRepository.GenerateMock, necesito establecer explícitamente expectativas en una llamada a un método específico para interceptar esa llamada. Con los apéndices, parece interceptar automáticamente cualquier método siempre que sea virtual.