¿Puedes explicar la diferencia entre StrictMock y Partialmock?

Question

Como estoy usando la versión 3.6 de RhinoMocks y como no estoy usando Record-Replay y no llamo a los métodos de verificación para reafirmar en los simulacros;

¿Puede explicarnos cuál es la diferencia entre simplemente?

MockRepository.GenerateMock() 
MockRepository.GeneratePartialMock() 
MockRepository.GenerateStrictMock() 

Nota: Yo uso .GenerateMock todo el tiempo para crear mis burla y afirmo método de llamadas por medio de argumentos ya la expectativa.

Answer 1

Las diferencias son explained in this article

Si crea expectativas en un StrictMock, y un método es llamado en el simulacro, se lanzará una excepción.

Si no crea expectativas en un PartialMock, y se invoca un método en el simulacro, no ocurre nada especial. Si ese simulacro deriva de una clase base, la llamada se transfiere a la implementación base existente.

También hay algo llamado DynamicMock. Si no crea expectativas en un DynamicMock, y se llama a un método en el simulacro, se llama a un método stub. Si hubo un valor de retorno, se devuelve un valor predeterminado (por ejemplo, null o 0).

GenerateMock Creo que crea un DynamicMock.

Ayende eligió este valor predeterminado porque recomienda un ideal de solo usar DynamicMock y Stub. StrictMock crea pruebas frágiles, y generalmente viola el concepto de solo verificar un comportamiento por prueba.

Ver este artículo: http://ayende.com/wiki/Rhino%20Mocks%203.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

También he visto que diga que es útil comenzar con burla estrictas, y trabajar sus pruebas de vuelta a los simulacros dinámicos/talones de una vez que se sienta cómodo con la forma en su código -under-test se está comportando. Ningún enlace para eso: :)

Answer 2

Tengo que añadir que "el uso de Strict Mock se desalienta" por las palabras de Ayende. http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

Dice:

burla estrictos fallarán si algo que no se espera ocurrirá a ellos. A largo plazo, esto significa que cualquier cambio al código bajo la prueba puede romper sus pruebas, incluso si el cambio no tiene nada que ver con lo que en realidad está probando en esta prueba específica.

En su lugar, recomiendo el uso de stubs y dynamic mocks.