2010-01-04 13 views
6

Usando Rhinomocks, ¿cómo puedo verificar que nunca se haya llamado un Mock/stub? ¿Significa que no se llamaron métodos al simulacro/stub?Rhinomocks, ¿cómo verificar que nunca se haya llamado un stub/mock?

Conozco el método AssertWasNotCalled, pero este método requiere que mencione un nombre de método. (Quizás tengo una clase con 10 métodos diferentes que podrían llamarse).

Log.AssertWasNotCalled(x => x.LogAndReportException(null, null), x => x.IgnoreArguments()); 

Respuesta

1

Usted puede utilizar el método StrictMock para crear una maqueta estricta - esto va a fallar si se utiliza cualquier llamada al método unexcepted. De acuerdo con Ayende's site, esto se desaconseja, pero parece exactamente el escenario en el que sería útil.

1

Cuando está utilizando simulaciones, no debe afirmar que cada llamada se realizó o no. Eso combina tus pruebas con una implementación en particular y las hace frágiles y una pesadilla de refactorización.

Si alguna vez me encontré con esta situación, volvería a pensar por qué quería afirmar que nunca se utilizó una dependencia.

Obviamente, si la dependencia no se usa en ningún lado, simplemente quítela. Si es necesario para algunas operaciones, pero todas las operaciones en la dependencia son operaciones destructivas y desea asegurarse de que algunas operaciones no dañen con ellas, debe afirmar explícitamente que las operaciones destructivas no fueron llamadas y permitir que la implementación lo haga. lo que quiera con las operaciones no destructivas (si hay alguna). Esto hace que tus pruebas sean más explícitas y menos frágiles.

+0

+1 En general, estoy de acuerdo, en particular cuando se trata de pruebas frágiles. Sin embargo, esta puede ser una solicitud válida. Imagine una interfaz con Method Injection. Como un método en la interfaz toma un parámetro abstracto inyectado, debe proporcionar algo. Supongamos ahora que está creando una implementación 'nula' de esa interfaz, y el requisito es que el parámetro inyectado (que debe estar presente debido a la interfaz) nunca se utilice. Un poco de un escenario de nicho, lo admito, pero sigue siendo relevante :) –

+0

@ Mark: sí, ese es un uso aceptable. Sabía que había algún caso en la esquina donde podría ser útil, simplemente no podría encontrar uno. –

+1

¿No es una prueba unitaria en una cláusula de guardia un buen lugar para asegurarse de que no se llamen las dependencias dentro del método? Actualmente estoy escribiendo una prueba unitaria para este escenario en el que deseo asegurarme de que la cláusula de guardia funcione según lo previsto y nunca se invoque el simulacro. – Maslow

6

Se puede utilizar una maqueta estricto, aunque incluya esta es una característica que puede desaparecer en el futuro:

var mocks = new MockRepository(); 
var cm = mocks.StrictMock<ICallMonitor>(); 
cm.Replay(); 

cm.HangUp(); // this will cause VerifyAllExpectations to throw 
cm.VerifyAllExpectations(); 

En esta sintaxis, un Strick Mock sólo permite llamadas explícitamente definidos.

+0

Si entiendo esto correctamente, en este escenario, ¿ninguno/ambos 'Replay' y' HangUp' harán que la verificación arroje? – Maslow

+2

@Maslow: no. 'Replay' es un método de extensión de Rhino Mocks que coloca el simulacro en el modo de reproducción. Antes estaba en modo de grabación y no registró llamadas realizadas en él. Cuando entre en el modo de reproducción, permitirá exactamente eso: no se pueden hacer llamadas en él. –

+0

ah, a menos que me falta el método de extensión o esto es de una versión diferente, en mi código era 'mocks.Replay (cm);' Then 'mocks.VerifyAll();' – Maslow

Cuestiones relacionadas