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

Question

Acabo de leer el artículo de Wikipedia en objetos simulados , pero todavía no estoy del todo claro. en 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 al 100% cuáles son los valores del objeto simulado porque 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 debe faltar algo. Por ejemplo, en un proyecto de curso, nos asignaron una aplicación de calendario. Nuestro conjunto de pruebas consistía en objetos de eventos que sabíamos exactamente lo que eran, por lo que podríamos probar las interacciones entre varios objetos de eventos, varios subsistemas y la interfaz de usuario. Supongo que estos son objetos simulados, pero no sé por qué no haría esto porque sin los objetos de valores conocidos, no puede 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.

Hay marcos 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 tome un int y devuelva un bool. Cuando paso 0, debería devolver verdadero. Luego puedes probar el código que usa foo (), para asegurarte de que reacciona adecuadamente.

Martin Fowler tiene un gran artículo sobre burlas:

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

Answer 2

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

Sin embargo, el objetivo del simulacro no es duplicar el comportamiento de las cosas, sino su simulacro. Es más como actuar como una simple máquina de estados cuyos cambios de estado pueden ser analizados por el marco de prueba. Por lo tanto, un cliente simulado podría generar datos de prueba, enviarlos al servidor y luego analizar la respuesta. Espera una respuesta determinada a una solicitud específica y, por lo tanto, puede probar si la recibe.

Answer 3

Estoy de acuerdo con todo @Lou Franco dice y definitivamente deberías leer el excelente artículo de Martin Fowler sobre pruebas de dobles que @Lou Franco te señala.

El propósito principal de cualquier prueba doble (falso, talón o simulacro) es aislar el objeto a prueba para que su prueba de unidad solo esté probando 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 pueda colocar la expectativa de que se producirán ciertas interacciones. Esto puede ser útil, pero existe cierta controversia sobre las pruebas basadas en el estado frente a las basadas en la interacción. El uso excesivo de la expectativa simulada llevará a pruebas frágiles.

Otra razón para duplicar las pruebas es eliminar las dependencias de las bases de datos o los sistemas de archivos u otros tipos que son costosos de configurar o realizar operaciones que requieren mucho tiempo. Esto significa que puede mantener al mínimo el tiempo necesario para realizar una prueba unitaria del objeto en el que está interesado.

Answer 4

Este es un ejemplo: si está escribiendo un código que llena una base de datos, es posible que desee 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 la prueba tiene el problema de que si asume que no hay registros antes de la llamada al método probado y un registro posterior, entonces debe revertir la base de datos a un estado anterior, agregando a la sobrecarga para ejecutar la prueba.

Si asume que solo hay un registro más que antes, puede chocar 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 frágiles las pruebas.

El simulacro le permite mantener las pruebas independientes entre sí y fáciles de configurar.

Este es solo un ejemplo: estoy seguro de que otros pueden proporcionar 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.

Answer 5

Es posible que esté interesado en nuestro libro, consulte http: //www.growing-object -orientado-software.com/ . Está en Java, pero las ideas aún se aplican.