Rhino Mocks - ¿Realmente necesitamos talones?

Question

Si es posible cambiar el comportamiento simulado en Rhino Mocks usando mock.Stub(). Return(), ¿por qué necesitamos Stubs de todos modos?

¿Qué perdemos utilizando siempre MockRepository.GenerateMock()?

Una gran ventaja de usar Mocks en lugar de Stubs es que podremos reutilizar la misma instancia entre todas las pruebas, manteniéndolas más limpias y directas.

El marco de moq funciona de manera similar ... no tenemos diferentes objetos para los burms y stubs.

(por favor, no responder con un enlace a Fowler de "burla no son talones de" artículo)

Answer 1

Hay una respuesta muy clara in the documentation:

Una maqueta es un objeto que nos puede establecer expectativas, y que será verificar que las acciones esperadas hayan ocurrido. Un stub es un objeto que utiliza para pasar al código bajo prueba. Puede expectativas de configuración en él, por lo que actuaría de ciertas maneras, pero esas expectativas nunca serán verificadas. Las propiedades de un código auxiliar se se comportarán automáticamente como propiedades normales, y usted no puede establecer las expectativas en ellas.

Si desea verificar el comportamiento del código bajo prueba, usará un simulacro con la expectativa apropiada y verifique eso. Si desea simplemente pasar un valor que pueda 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.

Answer 2

Ten en cuenta que Rhino ya no se desarrolla . marcos nuevos caen esta diferencia maqueta trozo completo e introducen solo término para su prueba duplica:

• Moq: simulacro
• FakeItEasy: falsa
• NSubstitute: sustituto

Evolución de moc King Frames parece presionar hacia "una entidad de propósito general", en lugar de tener diferentes diferentes según el contexto del caso de prueba.

Para aprender más sobre la forma en que la separación (maqueta, talón, falso) originó y qué fines sirve, sugiero la lectura de Mark Seemann's artículo sobre continuum of test doubles:

En un extremo encontrará maniquíes con absolutamente sin implementación, y en el otro extremo, implementaciones de producción completa.Los dummies y las implementaciones de producción están bien definidos, pero los stubs, los espías y las falsificaciones son más difíciles de precisar: ¿cuándo un espía de prueba se vuelve falso? Además, los simulacros habitan un intervalo bastante grande en el continuo, ya que pueden ser bastante complejos en algunos casos, pero muy simples en otros.

---

Podría parecer que Rhino no distingue entre simulacro y talón, pero hay diferencias sutiles. Por ejemplo, considere quitar getter de propiedad:

var mock = MockRepository.GenerateMock<IService>(); 
mock.Stub(m => m.Property).Return(42); 

Así es como debe hacerlo cuando el objeto es simulado. Stub por el contrario, presenta la semántica de propiedad , que trivializan cosa entera:

var stub = MockRepository.GenerateStub<IService>(); 
stub.Property = 42; 

A pesar de que es el único que viene a la mente en este momento, podría haber un poco más. Pero aún así, esos son solo pequeños matices.

_{1: A partir del 19/05/2013 , este ya no son válidas: Rhino Mocks new home}