testing - sismo - simulacro de evacuacion para niños
¿Qué es un simulacro y cuándo deberías usarlo? (5)
Aquí hay un ejemplo: si está escribiendo código que rellena una base de datos, puede verificar 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, entonces necesita retrotraer la base de datos a un estado anterior, lo que aumenta 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) que se conecta a la misma base de datos, lo que provoca dependencias y hace que las pruebas sean frágiles.
El simulacro le permite mantener las pruebas independientes una de la otra y es fácil de configurar.
Este es solo un ejemplo: estoy seguro de que otros pueden suministrar más.
Estoy de acuerdo al 100% con los otros colaboradores en este tema, especialmente con la recomendación para el artículo de Martin Fowler.
Acabo de leer el artículo de Wikipedia sobre objetos falsos , 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.
Estoy de acuerdo con todo @Lou Franco dice y definitivamente deberías leer el excelente artículo de Martin Fowler sobre dobles de prueba que @Lou Franco te señala.
El objetivo principal de cualquier prueba doble (falso, stub o simulacro) es aislar el objeto bajo prueba para que la prueba de su unidad solo pruebe ese objeto (no sus dependencias y los otros tipos con los que colabora o interactúa).
Un objeto que proporciona la interfaz de la que depende su objeto se puede usar en lugar de la dependencia real, de modo 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 dependencias en bases de datos o sistemas de archivos u otros tipos que son costosos 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.
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 son burlas. 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 podría 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.
Puede que le interese nuestro libro, consulte http://www.growing-object-oriented-software.com/ . Está en Java, pero las ideas aún se aplican.
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 excelente artículo sobre burlas: