GuíaBásico
Guía de Diagnóstico de Fallos de Test
Aprende a diagnosticar por qué falla un test — la habilidad que ninguna guía de "cómo escribir tests" cubre. Un test rojo es información, no un enemigo: esta guía te enseña el método científico del debugging (hipótesis → experimento) aplicado a fallos de pytest, empezando por leer un reporte de fallo sin ahogarte (el traceback, el assert-rewriting, `--showlocals`, `--tb=short/long/line`) y aislar el fallo hasta su reproducción mínima. Después entras al depurador interactivo con `pytest --pdb` y los comandos básicos de `pdb`, aprendes a diagnosticar tests flaky (que a veces pasan y a veces no) y tests con dependencia de orden o estado compartido, y cierras con la búsqueda binaria: usar `git bisect` para encontrar exactamente qué commit rompió un test. Todo el material práctico son suites de Reservo con fallos plantados a propósito, de distinto tipo, que aprendes a diagnosticar uno por uno. El proyecto final te entrega una suite rota con varios fallos de tipos distintos y te pide un log completo de diagnóstico — síntoma, hipótesis, experimento, causa y fix — por cada uno.
- 64
- lecciones
- 8
- módulos
- Inglés · Español
- disponible en
- Sí
- certificado
- Gratis
- acceso
Resultados
Lo que vas a poder hacer
- Adoptar la mentalidad correcta frente a un fallo: un test rojo es información, no un fracaso, y aplicar el método científico (hipótesis → experimento) al debugging
- Leer un reporte de fallo de pytest de punta a punta: el assert-rewriting, el traceback de abajo hacia arriba, `--showlocals`, `--tb=short/long/line`, y distinguir dónde ESTÁ el fallo de dónde se REPORTA
- Aislar y reproducir un fallo mínimamente: correr solo el test que falla (`-k`, nodeid), `--lf`/`--ff`, y reducir el ruido hasta la reproducción mínima
- Usar el depurador interactivo: `pytest --pdb` (post-mortem), `breakpoint()`/`--trace`, y los comandos básicos de `pdb` (`p`, `pp`, `l`, `w`, `n`, `s`, `c`) para inspeccionar el estado en el punto exacto del fallo
- Diagnosticar tests flaky (no deterministas): sus causas típicas (reloj, aleatoriedad, recursos externos, orden) y cómo reproducirlos de forma confiable
- Detectar dependencia de orden y estado compartido entre tests, incluyendo el uso de `pytest-randomly` para exponerlo
- Bisecar un problema con búsqueda binaria: usar `git bisect` para encontrar qué commit rompió un test, o bisecar a mano una suite grande hasta el test culpable
- Diagnosticar y arreglar una suite con varios fallos plantados de tipos distintos, entregando un log completo de diagnóstico por cada uno
Antes de empezar
Qué necesitas traer
Es para ti si...
- Devs que ya escriben tests pero se quedan atascados frente a un fallo que no entienden, sin un método para avanzar
- Equipos hartos de tests flaky que a veces pasan y a veces no, y no saben por dónde empezar a diagnosticarlos
- Devs que evitan el depurador y depuran a punta de `print()`, perdiendo tiempo en fallos que `pdb` resolvería en minutos
- Cualquiera que haya recibido un "se rompió en algún commit de la última semana" y necesite encontrar cuál
Requisitos y materiales
- Guía de Fundamentos de Testing y TDD completada (o equivalente: escribir y correr tests con pytest)
- Conocimientos básicos de git (commits, log) para el módulo de bisección
- Python 3.14 y pytest 9.1.1 instalados localmente (`pdb` 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: un test rojo es información
- 2. La mentalidad: un fallo es una pista, no un fracaso
- 3. La anatomía de un reporte de fallo de pytest
- 4. Dónde mirar primero
- 5. El método científico del debugging
- 6. Hipótesis y experimento
- 7. El antipatrón: cambiar cosas al azar
- 8. Mini-proyecto: diagnostica tres fallos de Reservo
- 1. Presentación del módulo: el reporte es un mapa, no un veredicto
- 2. El assert-rewriting: por qué pytest te muestra los valores
- 3. Leer el traceback de abajo hacia arriba
- 4. Controlar el traceback: las opciones `--tb`
- 5. `--showlocals`: ver las variables en el punto del fallo
- 6. Los errores comunes y qué significan
- 7. Dónde está el fallo vs dónde se reporta
- 8. Mini-proyecto: ubica la causa en tres reportes
- 1. Introducción: aislar es reducir el universo del fallo
- 2. Correr solo el test que falla, por nodeid
- 3. Filtrar con `-k`: aislar por lo que el nombre dice
- 4. `--lf` y `--ff`: dejar que pytest recuerde qué falló
- 5. Parar temprano: `-x` y `--maxfail`
- 6. Quitar el ruido de la corrida
- 7. La reproducción mínima: el menor código que sigue fallando
- 8. Mini-proyecto: aísla y reproduce el fallo en tres comandos
- 1. Presentación del módulo: el estado vivo que el reporte no te muestra
- 2. Qué es `pdb` y cuándo alcanzarlo
- 3. `pytest --pdb`: caer en el punto del fallo
- 4. `breakpoint()` y `pytest --trace`: entrar cuando tú quieras
- 5. Navegar la pila con `w`, `u` y `d`
- 6. Inspeccionar el estado con `p`, `pp` y `args`
- 7. Avanzar con `n`, `s` y `c`
- 8. Mini-proyecto: por qué `cancel` reembolsa el monto equivocado
- 1. Presentación del módulo: el fallo que rompe la repetición
- 2. Qué es un flaky y por qué es tóxico
- 3. El flaky del reloj: tests que dependen del tiempo
- 4. Reproducir un flaky: correrlo N veces
- 5. Aleatoriedad sin semilla
- 6. Recursos externos: red, disco y base de datos
- 7. Congelar el tiempo con inyección
- 8. Mini-proyecto: hacer determinista un flaky de Reservo
- 1. Presentación del módulo: el fallo que depende de quién corrió antes
- 2. El test que pasa solo y falla junto
- 3. Estado compartido de módulo y global
- 4. Fuga de fixtures por scope
- 5. Dependencia de orden de ejecución
- 6. Exponerlo con `pytest-randomly`
- 7. Diagnosticar el par culpable y aislarlo
- 8. Mini-proyecto: una suite que pasa en orden y falla aleatorizada
- 1. Presentación del módulo: encontrar cuándo se rompió
- 2. La búsqueda binaria: el superpoder del que diagnostica
- 3. `git bisect` paso a paso
- 4. `git bisect run`: automatizar la búsqueda
- 5. Bisecar una suite grande al test culpable
- 6. Bisecar datos y entrada al mínimo
- 7. Cuándo NO bisecar
- 8. Mini-proyecto: caza el commit culpable con `git bisect run`
- 1. Presentación del módulo: el proceso completo de diagnóstico
- 2. El assert de borde: el reembolso a 48 horas
- 3. El `KeyError`: un crash, no un valor equivocado
- 4. El flaky del reloj: reproducir y luego congelar
- 5. El fallo por orden y estado compartido
- 6. Bisecar la regresión en un repo desechable
- 7. Escribir el log de diagnóstico
- 8. Proyecto: diagnostica y arregla la suite rota
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!