Mocking, Stub, doubles
Contenido del curso
Mocking, Stub, doubles
Contenido del curso
Edgar Mauricio Pérez Rojas
Reinaldo Mendoza
Ronaldo Delgado
Andrés Pérez Díaz
Miguel Angel Hernandez Colombo
Alvaro Eduardo Garzón Pira
Ameth Ordoñez Erazo
Dany Ruddy Huayhua Huayhua
Willie David Roa Hidalgo
Iván Antonio Bustos Calderón
Reinaldo Mendoza
Jefred Bedoya
Alberto Alonso Acevedo
David Barrera
Alvaro Eduardo Garzón Pira
David Trespalacios
Ariel Ezequiel Biazzo Genua
Ronaldo Delgado
Jonathan Ardila
Carlos Rodríguez
Resumen Doubles
Dummy: Son datos ficticios para llenar información.
Fake: Son objetos que simulan comportamientos o datos; como un usuario ficticio.
Stubs: Son proveedores o APIs de tatos preparados (BD Clima).
Spies: Son como los stubs, pero se dejan espiar su comportamiento, comunicación e invocación.
Mocks: Stubs + Spies, pueden estar pre-programados para enviar las respuestas supuestas.
Gracias por el resumen
Gracias por el resumen!
Yo hice el código tal cual como el profesor y a mí sí me conecto a la DB y me trajo los datos de los dos libros. Milagro!!! jajaja
a mi no me conecto!
<$ docker-compose up -d mongo error during connect: this error may indicate that the docker daemon is not running: Get "htt://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.compose.project%3Dapi%22%3Atrue%7D%7D": open //./pipe/docker_engine: The system cannot find the file specified. >
Buen día a los dos
NOTA MENTAL: 💆♂️
Los Mocks es un tipo de prueba que consisten en crear objetos falsos que sustituyan a los objetos reales y de esta manera poder probar un determinado requerimiento. El objetivo de utilizar objetos fake en lugar de reales, es romper las dependencias con otros objetos y de esta manera probar requerimientos de manera independiente. Estos objetos se usan para probar que se realizan correctamente llamadas a otros métodos, por ejemplo, a una web API, y poder validar el comportamiento del componente al obtener una respuesta de parte de esa API.
Solo para destacar el comportamiento de docker. Una vez que docker se reinicia no guarda la información cargada en la bd, los libros de ejemplo que creamos se guardaron pero desaparecieron al levantar nuevamente el contenedor.
En esta clase efectivamente el profesor se conectó a la bd pero retornó un array sin elementos. El error se produjo debido a que un array vacío no tiene una longitud de 2.
Para quien está interesado en tener un contenedor con persistencia de datos se utiliza volumenes que son referencias a espacios de memoria fuera del contenedor donde le decimos a docker que guarde la información durante el uso del contedor.
Según chatGPT; Los doubles se utilizan en el contexto de pruebas unitarias y de integración para simular ciertos comportamientos o dependencias. Aquí hay una explicación de cada uno:
Dummy (Falso):
Ejemplo:
Supongamos que estás probando una función calculateTotal que toma dos parámetros: subtotal y impuesto. Si solo quieres probar cómo se calcula el total sin preocuparte por el impuesto, podrías pasar un Dummy como segundo parámetro: calculateTotal(100, dummy).
Fake (Falso):
Ejemplo:
En lugar de usar una base de datos real, podrías crear una clase FakeDatabase que simplemente almacene los datos en un diccionario en memoria. Esta implementación simplificada sería suficiente para las pruebas sin tener que depender de una base de datos real.
Stub (Tapa):
Ejemplo: Supongamos que estás probando una función que envía correos electrónicos. En lugar de enviar correos electrónicos reales durante la prueba, podrías usar un Stub que simule el comportamiento del servicio de correo electrónico y devuelva "éxito" inmediatamente sin enviar realmente el correo electrónico.
Spy (Espía):
Ejemplo: Supongamos que estás probando una función que llama a un servicio de registro. Puedes usar un Spy para registrar llamadas al servicio de registro durante la prueba y luego verificar si se llamó correctamente con los parámetros esperados.
Mock (Simulacro):
Ejemplo: Supongamos que estás probando una función que llama a un servicio de autenticación. Puedes usar un Mock para simular el servicio de autenticación y especificar expectativas sobre cómo debe llamarse durante la prueba. Luego, puedes verificar que se llamó correctamente con los parámetros esperados.
Creo que la dificultad del testing está justamente en esta clase. Los mocks. En el frontend esto se hace algo complejo de testear.
Esto es lo que los complica pero, es cuestión de entender que es una caja negra lo que simulas, entonces al final, evitas probar lo que no tienes que probar y dedicarte al test que te interesa
Para dominar las pruebas unitarias, necesitas distinguir cuándo y cómo sustituir dependencias. Aquí tienes la esencia:
Test Doubles: El concepto
Son objetos que reemplazan a los reales durante las pruebas para aislar la unidad bajo examen. No son todos iguales; cada uno tiene un propósito específico.
Tipos clave
Reglas de oro
Buenos días, no entiendo porque cuando trato de ejecutar el comando 'run test' a pesar que tengo la misma sintaxis que en el video me salta un error donde dice que debo tener al menos un test en el describe. Alguien podría ayudarme?
Comparte el código y el error por favor!
Hola Alberto, ¿Qué terminal usabas? Te recomendaría hacer uso de una basada en linux como Cmder, WSL o Bash
Hasta esta clase, no veo la utilidad de hacer pruebas al código con data simulada, a sabiendas que van a pasar las pruebas... sigamos adelante a ver que pasa.
Claro, pero si por ejemplo estas testeando un algoritmo complejo, en ese caso, utilizaras data simulada y muchas instrucciones que querras comprobar que tan bien se realizaron.
me quedare con los Mocks
Mocking, Stub, doubles
Doubles
Dummy: Son datos ficticios y se usan para rellenar información.
Fake: Simulan un objeto real y sirven para suplantar ciertos datos y comportamientos.
Stubs: Proveen respuestas preparadas y se pueden llamar durante el test para simular un comportamiento.
Spies: Pueden ser Stub pero puedo recolectar información de como fue llamado.
Mocks: Stub + Spies, a veces pueden ya estar pre-programados.
Este es el punto donde se considera que el patrón de diseño Singleton es un antipatrón, ya que si queremos es un conjunto de test crear una instancia por cada test no podremos hacerlo por la naturaleza creacional de ese patrón!
