La prueba aislada es más fácil. Como se mencionó en la introducción, probar una unidad (ya sea una clase, una función, un módulo, etc.) es más fácil de forma aislada que cuando depende de clases externas, funciones, módulos, etc. La cosa real no está disponible. En muchos casos es necesario simular parte de un sistema o una interfaz a otro sistema porque lo real simplemente no es disponible. Esto podría deberse a varias razones, entre ellas, que no se ha desarrollado todavía. En el curso natural del desarrollo de software, es probable que algunas partes de un sistema para ser desarrollado y listo para probar antes que otras partes. Si una parte depende de otra parte para algún elemento de su operación, entonces el sistema que aún no está disponible puede ser burlado. En otras situaciones, el equipo de desarrollo o el equipo de prueba pueden no tener acceso a lo real. Esto puede deberse a que solo está disponible dentro de una producción. contexto. Por ejemplo, si una casa de desarrollo de software está desarrollando un subsistema puede que no tenga acceso a otro subsistema ya que es propietario y solo accesible una vez que el software se ha implementado dentro de la organización del cliente. Los elementos reales pueden llevar mucho tiempo. Queremos que nuestras pruebas se ejecuten tan rápido como posible y ciertamente dentro de un entorno de integración continua (CI) queremos para que se ejecuten lo suficientemente rápido como para que podamos probar repetidamente un sistema a lo largo del día. En algunas situaciones, la cosa real puede tomar una cantidad significativa de tiempo para procesar la escenario de prueba. Como queremos probar nuestro propio código, es posible que no nos preocupe si un sistema fuera de nuestro control funciona correctamente o no (al menos en este nivel de prueba; todavía puede ser una preocupación para la integración y las pruebas del sistema). Podemos por lo tanto mejorar los tiempos de respuesta de nuestras pruebas si nos burlamos del sistema real y reemplácelo con un simulacro que proporciona tiempos de respuesta mucho más rápidos (posiblemente porque utiliza respuestas enlatadas). El real cosa acepta tiempo a colocar arriba. En a Continuo Integración (CI), las nuevas construcciones de un sistema se prueban regular y repetidamente (por ejemplo cada vez que se realiza un cambio en su base de código). En tales situaciones, puede ser necesario para configurar e implementar el sistema final en un entorno adecuado para realizar las pruebas correspondientes. Si la configuración de un sistema externo requiere mucho tiempo, implementarlo e inicializarlo puede ser más efectivo para simular ese sistema. Difícil emular ciertas situaciones. Puede ser difícil dentro de un escenario de prueba para emular situaciones específicas. Estas situaciones suelen estar relacionadas con errores o excepciones. circunstancias cionales que nunca deberían ocurrir dentro de un funcionamiento correcto ambiente. Sin embargo, bien puede ser necesario validar que si tal situación ocurre, entonces el software puede manejar ese escenario. Si estos escáneres son relacionado con cómo el sistema externo (la unidad bajo prueba) falla o funciona incorrectamente, entonces puede ser necesario simular estos sistemas para poder generar los escenarios. Queremos pruebas repetibles. Por su propia naturaleza, cuando ejecuta una prueba, usted desea que pase o falle cada vez que se ejecute con las mismas entradas. ciertamente no quieren pruebas que pasen a veces y fallen otras veces. Esto significa que no hay confianza en las pruebas y las personas a menudo comienzan a ignorar las pruebas fallidas. Esta situación puede 16.2 ¿Por qué burlarse? 189