Cuándo usar los simulacros parciales?

Question

Empiezo a sentirme cómodo con la idea de falsificaciones, trozos, burlas y burlas dinámicas. Pero todavía soy un poco dudoso en mi comprensión de cuándo usar burlas parciales.

Parece que si planea burlarse de un servicio y necesita recurrir a un simulacro parcial, entonces es un signo de mal diseño. ¿Es que los simulacros parciales son principalmente para obtener código heredado bajo cobertura de prueba?

Por otro lado, digamos que estoy probando una clase que tiene un método Reset(). Si ya he confirmado en una prueba separada que el método Reset() funciona, y tengo alguna funcionalidad de la clase que debe finalizar con una llamada a este método, ¿es un diseño de prueba deficiente hacer una simulación parcial del objeto y ejecutarlo? pruebas contra el simulacro parcial, que define una Expectativa en el método Restablecer().

Actualmente tengo varias pruebas configuradas de esta manera, ¿este tipo de cosas me van a dar problemas más adelante?

Answer 1

Mi comprensión de la simulación parcial era que era para burlarse de las clases abstractas, con solo burlarse de los métodos abstractos y dejar los métodos concretos existentes como están.

Answer 2

Its good design, imho. ¿Qué sucede cuando alguien viene detrás de usted y cambia su método, eliminando la llamada a Restablecer? (por cierto, ¿por qué tanto estado en tus objetos?). Quizás nunca sepas que se equivocaron hasta que alcanzas la producción. Al burlarse de él y afirmarlo en esa llamada a un método, puede asegurarse de que nadie va a cometer errores mientras mantiene su código.

Answer 3

Se podría argumentar que todos los simulacros son 'parciales' en el sentido de que no implementan completamente una interfaz. Como intenta probar una funcionalidad muy enfocada, solo debe burlarse de los aspectos de las clases de soporte que son necesarios para ejercer la funcionalidad que está probando.

Esto permitirá que su prueba se desacople de otras pruebas, lo cual es bueno.

Answer 4

En su ejemplo, parece que el método Reset es un detalle de implementación y al utilizar un simulacro parcial, corre el peligro de asociar su prueba a la implementación de la clase. Esto hará que su prueba sea más frágil de lo necesario.

También creo que hace que las pruebas sean más confusas para tener un objeto que tenga algunos métodos con implementaciones reales y algunas con implementaciones de stub. Es solo una cosa más para recordar cuando vuelvas a una prueba más tarde.

¿Puede (a) utilizar pruebas basadas en estado para afirmar que el estado del objeto es el esperado después de que el método real Reset se haya llamado internamente; o (b) usar pruebas basadas en interacciones para verificar que las llamadas relevantes a objetos colaboradores se hayan realizado como resultado del método real Reset?

Puede encontrar Test Smell: Mocking concrete classes de mockobjects.com useful.