¿Qué es un simulacro y cuándo deberías usarlo?

Question

Acabo de leer el artículo de Wikipedia en mock objects, pero aún no estoy del todo claro sobre su propósito. Parece que son objetos creados por un marco de prueba cuando el objeto real sería demasiado complejo o impredecible (usted sabe 100% seguro de cuáles son los valores del objeto simulado porque usted los controla por completo).

Sin embargo, tenía la impresión de que todas las pruebas se realizan con objetos de valores conocidos, por lo que me falta algo. Por ejemplo, en un proyecto de curso, nos encargaron una aplicación de calendario. Nuestro conjunto de pruebas constaba de objetos de eventos que sabíamos exactamente qué eran para poder probar las interacciones entre múltiples objetos de eventos, varios subsistemas y la interfaz de usuario. Supongo que estos son objetos simulados, pero no sé por qué no harías esto porque sin los objetos de valores conocidos, no puedes probar un sistema.

Answer 1

Un objeto simulado no es solo un objeto con valores conocidos. Es un objeto que tiene la misma interfaz que un objeto complejo que no puede usar en la prueba (como una conexión de base de datos y conjuntos de resultados), pero con una implementación que puede controlar en su prueba.

Existen frameworks burlones que te permiten crear estos objetos sobre la marcha y, en esencia, te permiten decir algo como: Hazme un objeto con un método foo que toma un int y devuelve un bool. Cuando pase 0, debería volverse verdadero. Luego puede probar el código que usa foo(), para asegurarse de que reacciona adecuadamente.

Martin Fowler tiene un gran artículo sobre burlona:

• http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

Piense en el caso clásico de tener software de cliente y servidor. Para probar al cliente, necesita el servidor; para probar el servidor, necesitas el cliente. Esto hace que las pruebas unitarias sean casi imposibles, sin usar simulacros. Si se burla del servidor, puede probar el cliente de forma aislada y viceversa.

El objetivo del simulacro no es duplicar el comportamiento de las cosas que simulan. Es más para actuar como una máquina de estado simple cuyos cambios de estado pueden analizarse mediante el marco de prueba. Entonces, un simulacro de cliente puede generar datos de prueba, enviarlos al servidor y luego analizar la respuesta. Espera una determinada respuesta a una solicitud específica, por lo que puede probar si la obtiene.

Answer 3

Estoy de acuerdo con todo lo que dice @Lou Franco y sin duda debe leer el excelente artículo de Martin Fowler en la prueba de dobles puntos que @Lou Franco usted a.

El objetivo principal de cualquier prueba doble (falso, stub o simulacro) es aislar el objeto bajo prueba para que la prueba unitaria solo pruebe ese objeto (no sus dependencias y los otros tipos con los que colabora o interactúa).

Se puede usar un objeto que proporciona la interfaz de la que depende su objeto en lugar de la dependencia real para que se puedan establecer expectativas de que se producirán ciertas interacciones. Esto puede ser útil, pero existe cierta controversia en torno a las pruebas basadas en el estado frente a las basadas en la interacción. El uso excesivo de la expectativa falsa dará lugar a pruebas frágiles.

Otra razón para los dobles de prueba es eliminar las dependencias en bases de datos o sistemas de archivos u otros tipos que son caros de configurar o que realizan operaciones que consumen mucho tiempo. Esto significa que puede mantener el tiempo requerido para probar al mínimo el objeto que le interesa.

Answer 4

Aquí hay un ejemplo: si está escribiendo código que rellena una base de datos, es posible que desee comprobar si un método en particular ha agregado datos a la base de datos.

La configuración de una copia de la base de datos para las pruebas tiene el problema de que si supone que no hay registros antes de la llamada al método probado y un registro después, debe volver la base de datos a un estado anterior, por lo tanto agregar a la sobrecarga para ejecutar la prueba.

Si supone que solo hay un registro más que antes, puede entrar en conflicto con un segundo probador (o incluso una segunda prueba en el mismo código) conectando a la misma base de datos, causando dependencias y haciendo frágiles las pruebas.

El simulacro le permite mantener las pruebas independientes unas de otras y es fácil de configurar.

Este es solo un ejemplo: estoy seguro de que otros pueden suministrar más.

Estoy de acuerdo 100% con los otros colaboradores en este tema, especialmente con la recomendación para el artículo de Martin Fowler.

Answer 5

Puede que le interese nuestro libro, vea http://www.growing-object-oriented-software.com/. Está en Java, pero las ideas aún se aplican.