mocking - test - ¿Cuáles son las diferencias entre los simulacros y los talones en Rhino Mocks?
test driven development book (5)
No he jugado lo suficiente con esto y generalmente uso simulaciones, 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 palabras de Ayende :
La diferencia entre trozos y burlas
Puede obtener la definición real de estos términos en este artículo: Mocks Are not Stubs . 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 hayan ocurrido. Un stub es un objeto que utiliza para pasar al código bajo prueba. Puede establecer expectativas en él, por lo que actuaría de ciertas maneras, pero esas expectativas nunca serán verificadas. Las propiedades de un stub 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, usará un simulacro con la expectativa apropiada y lo verificará. Si solo quiere pasar un valor que puede necesitar actuar de cierta manera, pero no es el objetivo de esta prueba, usará un stub.
IMPORTANTE: Un talón nunca hará que falle una prueba.
Diferencia entre Mock y stub: con stub, arregla la entrada de tu unidad de prueba: para que tu unidad de prueba no haga assertion en stub y Stub reescribiendo la implementación de algún método, corrija el comportamiento del objeto falso. con Mock, corrige la salida de la prueba de su unidad: por lo tanto, su prueba unitaria hace una expectativa sobre su objeto Mocking al verificar la interacción interna en su objeto simulado.
En el caso del framework Moq, el método de configuración es STUB donde el método Verify es Mock
En términos generales, las pruebas unitarias llaman a funciones y métodos, y luego verifican si se produjo el comportamiento esperado. Estas funciones y métodos pueden requerir parámetros. Usamos stubs y burlas para satisfacer estos parámetros. A veces también nos podemos burlar de los objetos globales.
Talones
Un Stub es un pequeño objeto falso que su prueba puede usar como parámetro para hacer que funcione la llamada a la función. 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.
Mocks
Un simulacro es un apéndice con una implementación. Si nuestra función bajo prueba interactúa con nuestro objeto simulado, podemos verificar que el simulacro se ha interactuado como esperábamos.
Por ejemplo, supongamos que tenemos un objeto de usuario falso y queremos verificar que nuestro método session.login funcionó, es posible que deseemos verificar que se haya establecido 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 apéndice con una implementación, que nos permite probar los efectos secundarios.
¿Esta diferencia sigue siendo importante?
Más bien como la diferencia entre símiles y metáforas, la diferencia entre trozos y burlas es sutil e histórica, y tal vez tiene 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 talón. Un stub generalmente se puede expandir a un simulacro.
¿Cuál deberías usar?
Puede descubrir que comienza a crear stubs, y luego puede encontrar que necesita crear full en simulaciones para algunos de sus objetos. Es posible que desee burlarse de todo sobre la marcha, o simplemente puede querer burlarse cuando sea necesario.
Según this
... En pocas palabras, existe una diferencia entre los objetos Mock y Stub y RhinoMocks reconoce que nos permite escribir pruebas que indiquen mejor su propósito.
Los objetos simulados se usan para definir las expectativas, es decir: en este escenario, espero que se llame al método A () con dichos parámetros. Se burla de registrar y verificar tales expectativas.
Los stubs, 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 ...
Una cosa que noté también es que cuando uso MockRepository.GenerateMock, necesito establecer explícitamente las expectativas sobre una llamada a un método específico para interceptar esa llamada. Con los stubs, parece interceptar automáticamente cualquier método, siempre que sea virtual.