Otras respuestas explican lo que es burlarse. Déjame guiarte con diferentes ejemplos . Y créeme, en realidad es mucho más simple de lo que piensas.
tl; dr Es una instancia de la clase original. Tiene otros datos inyectados para que evite probar las partes inyectadas y se centre únicamente en probar los detalles de implementación de su clase / funciones.
Un simple ejemplo:
class Foo {
func add (num1: Int, num2: Int) -> Int { // Line A
return num1 + num2 // Line B
}
}
let unit = Foo() // unit under test
assertEqual(unit.add(1,5),6)
Como puede ver, no estoy probando LineA, es decir, no estoy validando los parámetros de entrada. No estoy validando para ver si num1, num2 son un número entero. No tengo afirmaciones en contra de eso.
Solo estoy probando para ver si LineB (mi implementación ) da los valores simulados 1y 5está haciendo lo que esperaba.
Obviamente, en la palabra real, esto puede volverse mucho más complejo. Los parámetros pueden ser un objeto personalizado como una Persona, Dirección, o los detalles de implementación pueden ser más de uno +. Pero la lógica de las pruebas sería la misma.
Ejemplo de no codificación:
Suponga que está construyendo una máquina que identifica el tipo y la marca de los dispositivos electrónicos para la seguridad de un aeropuerto. La máquina hace esto procesando lo que ve con su cámara.
Ahora su gerente entra por la puerta y le pide que lo pruebe en la unidad.
Luego, como desarrollador, puede traer 1000 objetos reales, como un MacBook pro, Google Nexus, un plátano, un iPad, etc. delante y probar y ver si todo funciona.
Pero también puede usar objetos burlados , como un MacBook pro de aspecto idéntico (sin partes internas reales) o un plátano de plástico frente a él. Puede ahorrarse de invertir en 1000 computadoras portátiles reales y plátanos podridos.
El punto es que no estás tratando de probar si el plátano es falso o no. Tampoco probar si la computadora portátil es falsa o no. Todo lo que estamos haciendo es probar si su máquina una vez que se ve un plátano que diría not an electronic devicey por un MacBook Pro que diría: Laptop, Apple. Para la máquina, el resultado de su detección debe ser el mismo para la electrónica falsa / burlada y la electrónica real
La lógica mencionada anteriormente se aplica también a las pruebas unitarias del código real. Esa es una función que debería funcionar de la misma manera con los valores reales que obtienes de la entrada real (y las interacciones) o burladosvalores que inyecta durante las pruebas unitarias. Y de la misma manera en que se ahorra el uso de una banana real o una MacBook, con pruebas unitarias (y burlas) se ahorra tener que hacer algo que haga que su servidor devuelva un código de estado de 500, 403, 200, etc. (forzando su servidor para activar 500 es solo cuando el servidor está inactivo, mientras que 200 es cuando el servidor está activo. Se hace difícil ejecutar 100 pruebas centradas en la red si tiene que esperar constantemente 10 segundos entre el cambio de servidor hacia arriba y hacia abajo). Entonces, en su lugar, inyecta / se burla de una respuesta con el código de estado 500, 200, 403, etc. y prueba su unidad / función con un valor inyectado / burlado.
Ejemplo de codificación:
Supongamos que está escribiendo una aplicación para iOS y tiene llamadas de red. Su trabajo es probar su aplicación. Probar / identificar si las llamadas de red funcionan o no como se espera NO ES SU RESPONSABILIDAD. Es responsabilidad de otra parte (equipo del servidor) probarlo. Debe eliminar esta dependencia (de red) y, sin embargo, continuar probando todo el código que funciona a su alrededor .
Una llamada de red puede devolver diferentes códigos de estado 404, 500, 200, 303, etc. con una respuesta JSON.
Se supone que su aplicación funciona para todos ellos (en caso de errores, su aplicación debería arrojar el error esperado). Lo que hace con burlarse es crear respuestas de red 'imaginarias, similares a las reales' (como un código 200 con un archivo JSON) y probar su código sin 'hacer la llamada de red real y esperar su respuesta de red'. Usted codifica / devuelve manualmente la respuesta de red para TODOS los tipos de respuestas de red y comprueba si su aplicación funciona como espera. ( nunca asume / prueba un 200 con datos incorrectos, porque esa no es su responsabilidad, su responsabilidad es probar su aplicación con un 200 correcto, o en el caso de un 400, 500, prueba si su aplicación arroja el error correcto)
Esta creación imaginaria, similar a la real, se conoce como burla.
Para hacer esto, no puede usar su código original (su código original no tiene las respuestas previamente insertadas, ¿verdad?). Usted debe agregar algo a ella, inyecte / insertar datos ficticios que los que normalmente no se necesitan (o una parte de su clase).
Entonces, crea una instancia de la clase original y agrega lo que sea (aquí es la red HTTPResponse, datos O en el caso de falla, le pasa el errorString correcto, HTTPResponse) que necesita y luego prueba la clase burlada .
En pocas palabras, burlarse es simplificar y limitar lo que está probando y también hacer que alimente de lo que depende una clase. En este ejemplo, evita probar las llamadas de la red y, en cambio, prueba si su aplicación funciona o no como espera con las salidas / respuestas inyectadas , burlándose de las clases
No hace falta decir que prueba cada respuesta de red por separado.
Ahora, una pregunta que siempre tuve en mente fue: Los contratos / puntos finales y básicamente la respuesta JSON de mis API se actualizan constantemente. ¿Cómo puedo escribir pruebas unitarias que tengan esto en cuenta?
Para elaborar más sobre esto: digamos que el modelo requiere una clave / campo llamado username. Usted prueba esto y su prueba pasa. 2 semanas después, el backend cambia el nombre de la clave a id. Tus pruebas aún pasan. ¿Correcto? ¿o no?
¿Es responsabilidad del desarrollador del backend actualizar los simulacros? ¿Debería ser parte de nuestro acuerdo que proporcionen simulacros actualizados?
La respuesta al problema anterior es que: las pruebas unitarias + su proceso de desarrollo como desarrollador del lado del cliente deberían / podrían detectar una respuesta simulada obsoleta. Si me preguntas cómo? bueno la respuesta es:
Nuestra aplicación real fallaría (o no fallaría aún sin tener el comportamiento deseado) sin usar API actualizadas ... por lo tanto, si eso falla ... haremos cambios en nuestro código de desarrollo. Lo que nuevamente lleva a que nuestras pruebas fallen ... y tendremos que corregirlo. (En realidad, si vamos a hacer el proceso TDD correctamente, no debemos escribir ningún código sobre el campo a menos que escribamos la prueba para él ... y veamos que falla y luego vamos y escribimos el código de desarrollo real para él).
Todo esto significa que el backend no tiene que decir: "oye, actualizamos los simulacros" ... eventualmente sucede a través del desarrollo / depuración de su código. ّ ¡Porque todo es parte del proceso de desarrollo! Aunque si el backend proporciona la respuesta burlada para usted, entonces es más fácil.
Todo mi punto sobre esto es que (si no puede automatizar la actualización de la respuesta de API simulada ), se requiere cierta interacción humana, es decir, actualizaciones manuales de JSON y reuniones cortas para asegurarse de que sus valores estén actualizados formarán parte de su proceso
Esta sección fue escrita gracias a una discusión floja en nuestro grupo de reunión CocoaHead
Solo para desarrolladores de iOS:
Un muy buen ejemplo de burla es esta charla práctica orientada al protocolo de Natasha Muraschev . Simplemente pase al minuto 18:30, aunque las diapositivas pueden no estar sincronizadas con el video real 🤷♂️
Realmente me gusta esta parte de la transcripción:
Debido a que esto es una prueba ... queremos asegurarnos de que se llame a la getfunción desde Gettable, porque puede regresar y, en teoría, la función podría asignar una variedad de alimentos desde cualquier lugar . Necesitamos asegurarnos de que se llame;