GuíaBásico
Guía de Dobles de Prueba y Datos de Test
Aprende a aislar la unidad bajo prueba de sus colaboradores con dobles de prueba (dummy, stub, spy, mock, fake) y a manejar los datos de test sin ahogarte en setup. Esta guía continúa el caso Reservo justo donde termina la de fundamentos: ahora reservar y cancelar tocan el mundo exterior a través de un `BookingService` que orquesta cuatro colaboradores — un `Clock` para la hora, un `PaymentGateway` para cobrar y reembolsar, un `EmailSender` para confirmar, y un `BookingRepository` para persistir. Ahí es donde los dobles se vuelven necesarios: no puedes probar contra un servicio de pago real en cada test. Aprendes el vocabulario preciso de la taxonomía de Meszaros, a stubear lo que ENTRA a la unidad, a verificar con mocks y spies lo que SALE, a construir un fake que funciona de verdad, y a reconocer el "infierno de mocks" que acopla tus tests a la implementación. Cierra con el patrón Builder para datos de test que se leen por intención, y un proyecto final donde eliges y justificas el doble correcto para cada colaborador del `BookingService`.
- 64
- lecciones
- 8
- módulos
- Inglés · Español
- disponible en
- Sí
- certificado
- Gratis
- acceso
Resultados
Lo que vas a poder hacer
- Distinguir la unidad bajo prueba de sus colaboradores, y entender por qué NO usar un servicio real (lento, con costo, no determinista) en un test unitario
- Dominar el vocabulario preciso de dobles de prueba: dummy, stub, spy, mock y fake (taxonomía de Meszaros), y distinguir verificación de estado vs. de comportamiento
- Escribir stubs que controlan lo que ENTRA a la unidad (respuestas enlatadas) para probar caminos felices y de fallo, sin sobre-especificar
- Escribir mocks y spies que verifican lo que SALE de la unidad (`unittest.mock`: `Mock`, `assert_called_once_with`, `call_args`) y reconocer cuándo esa verificación es excesiva
- Construir un fake que funciona de verdad (un repositorio en memoria) y entender el contract test que lo mantiene honesto contra la implementación real
- Reconocer el infierno de mocks: tests acoplados a la implementación que se rompen en cada refactor, y las escuelas London vs. Detroit
- Usar el patrón Builder y otros datos de test (object mother, factories, defaults sensatos) para que un test se lea por intención, no por ruido de setup
- Elegir el doble correcto para cada colaborador en un caso real (stub para consultas, spy/mock para efectos de salida, fake para persistencia) y justificar la elección
Antes de empezar
Qué necesitas traer
Es para ti si...
- Devs que ya completaron los fundamentos de testing/TDD y ahora necesitan aislar unidades que dependen de colaboradores externos (pagos, email, persistencia)
- Devs que abusan de `unittest.mock` sin criterio y terminan con suites frágiles que se rompen en cada refactor
- Equipos que necesitan datos de test legibles en vez de objetos armados a mano línea por línea
- Devs que quieren decidir con criterio cuándo doblar un colaborador y cuándo probarlo de verdad
Requisitos y materiales
- Guía de Fundamentos de Testing y TDD completada (o equivalente: correr pytest, ciclo rojo-verde-refactor, asserts, fixtures básicas, parametrize)
- Conocimientos básicos de Python orientado a objetos (clases, inyección de dependencias por constructor)
- Python 3.14 y pytest 9.1.1 instalados localmente (`unittest.mock` es de la librería estándar)
Contenido
El temario, módulo por módulo
Abre cualquiera para ver sus lecciones.
- 1. Presentación del módulo: Reservo crece y aparecen los colaboradores
- 2. Qué es un colaborador
- 3. El problema de la dependencia real
- 4. Efectos secundarios, no determinismo y costo
- 5. La costura y la inyección de dependencias
- 6. Código testeable contra código no testeable
- 7. El fake clock, revisitado
- 8. Mini-proyecto: haz testeable a `book` inyectando sus colaboradores
- 1. Presentación del módulo: cinco dobles, cinco trabajos
- 2. El dummy: un relleno que nunca se usa
- 3. El stub: respuestas enlatadas para controlar lo que entra
- 4. El spy: registra cómo lo llamaron
- 5. El mock: expectativas por adelantado
- 6. El fake: una implementación de mentira que sí funciona
- 7. Verificación de estado vs. de comportamiento
- 8. Mini-proyecto: ponle nombre a cada doble
- 1. Presentación del módulo: verificar lo que sale
- 2. Verificación de comportamiento: lo que sale no deja estado
- 3. El spy hecho a mano
- 4. El `Mock` de `unittest.mock`
- 5. `assert_called_once_with` y `call_args`
- 6. Verificar el monto del cobro
- 7. Verificar que una llamada NO ocurrió
- 8. Mini-proyecto: verifica los efectos de `book`
- 1. Presentación del módulo: el fake, una implementación que funciona
- 2. Qué es un fake
- 3. Un `FakeBookingRepository` con un `dict`
- 4. Un fake que se comporta de verdad: guardar y leer
- 5. Cuándo el fake le gana al stub o al mock
- 6. El peligro: un fake puede divergir del real
- 7. El contract test que mantiene honesto al fake
- 8. Mini-proyecto: escribe un fake y su contract test
- 1. Presentación del módulo: el peligro de sobre-especificar
- 2. Qué es sobre-especificar
- 3. El test que se rompe al refactorizar sin cambiar comportamiento
- 4. No mockees lo que no es tuyo
- 5. No mockees value objects
- 6. London vs. Detroit
- 7. Estado por defecto, comportamiento con moderación
- 8. Mini-proyecto: rescata una suite mock-pesada y frágil
- 1. Presentación del capstone: el proceso de elegir el doble
- 2. Elige el doble para cada colaborador
- 3. `book`, camino feliz, con la mezcla
- 4. `book` con un pago rechazado
- 5. `cancel` con fake repo y reloj fijo
- 6. Verifica el efecto sin sobre-especificar
- 7. Usa el builder para la legibilidad
- 8. Proyecto: testea `BookingService` con la mezcla correcta de dobles
Dudas frecuentes
Lo que suele preguntarse
Sin límite. Es una guía gratuita: entras cuando quieras, las veces que quieras.
No. Los módulos están ordenados de menos a más, pero puedes saltar al que necesites. Tu progreso se guarda por lección.
Lo que haga falta está en «Qué necesitas traer», arriba. Si no aparece nada ahí, puedes empezar desde cero.
En el grupo de WhatsApp del Club, y cada quince días hay un live con un instructor donde se resuelven dudas en vivo.
Sí. Al terminar todas las lecciones se emite automáticamente, con un código verificable que puedes compartir en LinkedIn.
Empieza cuando quieras
Lo que dicen los estudiantes
Estas reseñas son de estudiantes inscritos que completaron al menos el 50% del curso. Moderamos las reseñas solo por motivos de contenido (spam, lenguaje ofensivo, datos personales), nunca por ser críticas o negativas.
Aún no hay reseñas aprobadas.
¡Sé el primero en compartir tu experiencia!