Objeto simulado

En la programación orientada a objetos , los objetos simulados son objetos simulados que imitan el comportamiento de los objetos reales de forma controlada, la mayoría de las veces como parte de una iniciativa de prueba de software . Un programador generalmente crea un objeto simulado para probar el comportamiento de algún otro objeto, de la misma manera que un diseñador de automóviles usa un maniquí de prueba de choque para simular el comportamiento dinámico de un ser humano en impactos de vehículos. La técnica también es aplicable en programación genérica .

Motivación

En una prueba unitaria , los objetos simulados pueden simular el comportamiento de objetos reales complejos y, por lo tanto, son útiles cuando un objeto real es impráctico o imposible de incorporar a una prueba unitaria. Si un objeto tiene alguna de las siguientes características, puede resultar útil utilizar un objeto simulado en su lugar:

• el objeto proporciona resultados no deterministas (por ejemplo, la hora actual o la temperatura actual);
• tiene estados que son difíciles de crear o reproducir (por ejemplo, un error de red);
• es lento (por ejemplo, una base de datos completa , que debería inicializarse antes de la prueba);
• todavía no existe o puede cambiar el comportamiento;
• tendría que incluir información y métodos exclusivamente con fines de prueba (y no para su tarea real).

Por ejemplo, un programa de reloj de alarma que hace que suene una campana a una hora determinada puede obtener la hora actual de un servicio horario. Para probar esto, la prueba debe esperar hasta la hora de la alarma para saber si ha tocado la campana correctamente. Si se usa un servicio de tiempo simulado en lugar del servicio de tiempo real, se puede programar para proporcionar el tiempo de timbre (o cualquier otro tiempo) independientemente del tiempo real, de modo que el programa del despertador se pueda probar de forma aislada.

Detalles técnicos

Los objetos simulados tienen la misma interfaz que los objetos reales que imitan, lo que permite que un objeto cliente no sepa si está utilizando un objeto real o un objeto simulado. Muchos marcos de trabajo de objetos simulados permiten al programador especificar qué métodos se invocarán en un objeto simulado y en qué orden y qué parámetros se les pasarán, así como los valores que se devolverán. Por lo tanto, el comportamiento de un objeto complejo, como un conector de red, puede ser imitado por un objeto simulado, lo que permite al programador descubrir si el objeto que se está probando responde adecuadamente a la amplia variedad de estados en los que pueden encontrarse dichos objetos simulados.

Simulacros, falsificaciones y talones

La clasificación entre simulacros, falsificaciones y talones es muy inconsistente en la literatura. ^{[1] [2] [3] [4] [5] [6] Sin} embargo, coherente entre la literatura es que todos representan un objeto de producción en un entorno de prueba al exponer la misma interfaz.

Cuál de simulacro , falso o código auxiliar es el más simple es inconsistente, pero el más simple siempre devuelve respuestas preestablecidas (como en un código auxiliar de método ). En el otro lado del espectro, el objeto más complejo simulará completamente un objeto de producción con lógica completa, excepciones, etc. Si alguno de los tríos simulados, falsos o falsos se ajusta o no a tal definición es, nuevamente, inconsistente en todos los aspectos. literatura.

Por ejemplo, una implementación de método simulado, falso o de código auxiliar entre los dos extremos del espectro de complejidad puede contener afirmaciones para examinar el contexto de cada llamada. Por ejemplo, un objeto simulado puede afirmar el orden en el que se llaman sus métodos o afirmar la coherencia de los datos entre las llamadas a métodos.

En el libro The Art of Unit Testing ^{[7], las} simulaciones se describen como un objeto falso que ayuda a decidir si una prueba falló o pasó al verificar si se produjo una interacción con un objeto. Todo lo demás se define como un talón. En ese libro, las falsificaciones son cualquier cosa que no sea real, que, según su uso, puede ser talones o simulaciones .

Establecer expectativas

Considere un ejemplo en el que se ha simulado un subsistema de autorización. El objeto simulado implementa un método isUserAllowed(task : Task) : boolean^[8] para que coincida con el de la clase de autorización real. Se siguen muchas ventajas si también expone una isAllowed : booleanpropiedad, que no está presente en la clase real. Esto permite que el código de prueba establezca fácilmente la expectativa de que a un usuario se le otorgará o no permiso en la próxima llamada y, por lo tanto, probará fácilmente el comportamiento del resto del sistema en cualquier caso.

De manera similar, la configuración de solo simulacro podría garantizar que las llamadas posteriores al subsistema provocarán que se produzca una excepción , se cuelgue sin responder o regrese, nulletc. Por lo tanto, es posible desarrollar y probar comportamientos del cliente para condiciones de falla realistas en el back-end. subsistemas, así como por sus respuestas esperadas. Sin un sistema de simulación tan simple y flexible, probar cada una de estas situaciones puede ser demasiado laborioso para que se les dé la debida consideración.

Escribir cadenas de registro

El save(person : Person)método de un objeto de base de datos simulado puede no contener mucho código de implementación (si es que lo hay). Podría verificar la existencia y quizás la validez del objeto Person que se pasó para guardar (ver la discusión sobre falso vs. simulado arriba), pero más allá de eso, puede que no haya otra implementación.

Es una oportunidad perdida. El método simulado podría agregar una entrada a una cadena de registro público. La entrada no necesita ser más que "Persona guardada", ^{[9] : 146–7} o puede incluir algunos detalles de la instancia del objeto de persona, como un nombre o ID. Si el código de prueba también verifica el contenido final de la cadena de registro después de varias series de operaciones que involucran la base de datos simulada, entonces es posible verificar que en cada caso se haya realizado exactamente el número esperado de guardados de la base de datos. Esto puede encontrar errores invisibles que merman el rendimiento, por ejemplo, cuando un desarrollador, nervioso por perder datos, ha codificado llamadas repetidas save()donde solo una hubiera sido suficiente.

Uso en desarrollo impulsado por pruebas

Los programadores que trabajan con el método de desarrollo basado en pruebas (TDD) utilizan objetos simulados al escribir software. Los objetos simulados cumplen los requisitos de interfaz de los reales más complejos y los reemplazan; por lo tanto, permiten a los programadores escribir y realizar pruebas unitarias de funcionalidad en un área sin llamar a clases complejas subyacentes o colaboradoras . ^{[9] : 144–5 El} uso de objetos simulados permite a los desarrolladores enfocar sus pruebas en el comportamiento del sistema bajo prueba sin preocuparse por sus dependencias. Por ejemplo, probar un algoritmo complejo basado en que varios objetos se encuentren en estados particulares se puede expresar claramente utilizando objetos simulados en lugar de objetos reales.

Aparte de los problemas de complejidad y los beneficios obtenidos de esta separación de preocupaciones , hay problemas prácticos relacionados con la velocidad. Desarrollar una pieza de software realista usando TDD puede involucrar fácilmente varios cientos de pruebas unitarias. Si muchos de estos inducen la comunicación con bases de datos, servicios web y otros sistemas fuera de proceso o en red , entonces el conjunto de pruebas unitarias rápidamente se volverá demasiado lento para ejecutarse con regularidad. Esto, a su vez, conduce a malos hábitos y una renuencia por parte del desarrollador a mantener los principios básicos de TDD.

Cuando los objetos simulados se reemplazan por objetos reales, la funcionalidad de un extremo a otro necesitará más pruebas. Estas serán pruebas de integración en lugar de pruebas unitarias.

Limitaciones

El uso de objetos simulados puede acoplar estrechamente las pruebas unitarias a la implementación del código que se está probando. Por ejemplo, muchos marcos de trabajo de objetos simulados permiten al desarrollador verificar el orden y el número de veces que los métodos de objetos simulados fueron invocados por el objeto real que se está probando; refactorización posteriordel código que se está probando, por lo tanto, podría hacer que la prueba falle a pesar de que todos los métodos de objetos simulados siguen cumpliendo el contrato de la implementación anterior. Esto ilustra que las pruebas unitarias deben probar el comportamiento externo de un método en lugar de su implementación interna. El uso excesivo de objetos simulados como parte de un conjunto de pruebas unitarias puede resultar en un aumento dramático en la cantidad de mantenimiento que debe realizarse en las pruebas mismas durante la evolución del sistema a medida que se lleva a cabo la refactorización. El mantenimiento inadecuado de tales pruebas durante la evolución podría permitir que se pasen por alto errores que de otro modo serían detectados por pruebas unitarias que usan instancias de clases reales. Por el contrario, simplemente burlarse de un método puede requerir mucha menos configuración que configurar una clase real completa y, por lo tanto, reducir las necesidades de mantenimiento.

Los objetos simulados tienen que modelar con precisión el comportamiento del objeto del que se burlan, lo que puede ser difícil de lograr si el objeto que se está burlando proviene de otro desarrollador o proyecto o si aún no se ha escrito. Si el comportamiento no se modela correctamente, las pruebas unitarias pueden registrar un pase aunque se produzca una falla en el tiempo de ejecución bajo las mismas condiciones en las que se está ejercitando la prueba unitaria, lo que hace que la prueba unitaria sea inexacta. ^[10]

Ver también

• Método abstracto
• Código ficticio
• Stub de método
• Prueba doble

Referencias

1. "Hablemos el mismo idioma (falsos, stubs y simulacros)" .
2. "detrás de los tiempos: los farsantes y los talones no son espías" . 21 de octubre de 2007.
3. "Simulacros, falsificaciones, talones y maniquíes en XUnitPatterns.com" .
4. "¿Cuál es la diferencia entre un simulacro y un talón?" .
5. "¿Cuál es la diferencia entre fingir, burlarse y golpear?" .
6. Plumas, Michael (2005). "Detección y separación". Trabajar de forma eficaz con código heredado . Nueva Jersey: Prentice Hall. pag. 23 y siguientes. ISBN 0-13-117705-2.
7. Osherove, Roy (2009). "Pruebas de interacción con objetos simulados et seq". El arte de las pruebas unitarias . Manning. ISBN 978-1-933988-27-6.
8. Estos ejemplos utilizan una nomenclatura similar a la utilizada en el lenguaje de modelado unificado
9. Beck, Kent (2003). Desarrollo basado en pruebas por ejemplo . Boston: Addison Wesley. ISBN 0-321-14653-0.
10. InJava.com para burlarse | O'Reilly Media

enlaces externos

• Tim Mackinnon (8 de septiembre de 2009). "Una breve historia de los objetos simulados" . Mockobjects.com/.
• Test Doubles : una sección de un libro sobre patrones de pruebas unitarias.
• ¡Todo sobre objetos simulados! Portal sobre objetos simulados
• "Uso de objetos simulados para pruebas unitarias complejas" . IBM developerWorks. 16 de octubre de 2006. Archivado desde el original el 4 de mayo de 2007.
• Prueba unitaria con objetos simulados IBM developerWorks
• Mocks Aren't Stubs ( Martin Fowler ) Artículo sobre el desarrollo de pruebas con objetos Mock. Identifica y compara las escuelas de pruebas "clásicas" y "burlonas". Toca puntos sobre el impacto en el diseño y el mantenimiento.