Ahora puede ser necesario verificar las actualizaciones de datos realizadas en la base de datos, o la información enviado a un servicio remoto, etc. para confirmar que la operación del objeto de una clase es correcto. Esto hace que no solo el software que se está probando sea más complejo, sino que también hace que las pruebas en sí sean más complejas. Esto significa que hay una mayor probabilidad que la prueba fallará, que las pruebas contendrán errores o problemas y que la prueba será más difícil de entender y mantener para alguien. Así un común El objetivo al escribir pruebas unitarias o pruebas de subsistemas es poder probar elementos/ unidades en aislamiento. La pregunta es cómo hacer esto cuando una función o método se basa en otros ¿elementos? La clave para desacoplar funciones, métodos y objetos de otro programa o elementos del sistema es usar simulacros. Estos simulacros se pueden usar para desacoplar un objeto de otra, una función de otra y un sistema de otro; de este modo simplificar el entorno de prueba. Estos simulacros solo están destinados a ser utilizados para propósitos de prueba, por ejemplo, el escenario anterior podría simplificarse burlándose cada uno de los sistemas externos como se muestra a continuación: La simulación no es un concepto específico de Python y hay muchas bibliotecas de simulación disponible para muchos idiomas diferentes. Sin embargo, en este capítulo nos centraremos en la biblioteca unes.mock que ha sido parte de la distribución estándar de Python desde Python 3.3. 16.2 ¿Por qué burlarse? Una primera pregunta útil a considerar con respecto a la burla, en las pruebas de software, es ‘¿Por qué burlarse?’. Es decir, ¿por qué molestarse con el concepto de un simulacro en primer lugar; ¿Por qué no probar con la cosa real? Hay varias respuestas a esto, algunas de las cuales se discuten a continuación: 188 dieciséis Burlarse para probar