Lenguajes y Fundamentos de Programación · PY-107

Testing y TDD en Python

Pruebas unitarias, fixtures y desarrollo dirigido por pruebas aplicados a proyectos técnicos reales.

Disponible Avanzado 7 módulos · 34 clases

Formato asíncrono Desarrollo Python

DESARROLLO

Lo que aprenderás

Escribir pruebas unitarias con pytest usando assert, parametrización y comprobación de excepciones
Aislar dependencias externas con dobles de prueba y monkeypatch para probar sin red ni base de datos
Organizar datos y estado común en fixtures con el ámbito adecuado a cada caso
Aplicar el ciclo rojo-verde-refactor para incorporar una funcionalidad nueva guiada por pruebas
Medir la cobertura e interpretarla sin convertirla en un objetivo vacío
Ejecutar la batería de pruebas de forma automática en cada cambio con integración continua
Escribir una prueba que reproduzca un fallo reportado antes de corregirlo

Contenido del curso

7 módulos · 34 clases en vídeo · práctica guiada en cada módulo

Módulo 1 · Punto de partida 5 clases

Qué cuesta realmente un proyecto sin pruebas
Tipos de prueba: unitaria, integración y extremo a extremo
Instalación de pytest y estructura del proyecto
Primera prueba y primera ejecución
Lectura del informe de fallos

Módulo 2 · Escribir buenas pruebas 5 clases

Una prueba, una afirmación clara
Nombres que describen el comportamiento esperado
Parametrizar casos con parametrize
Comprobar que se lanza la excepción correcta
Comparación de flotantes y de estructuras

Módulo 3 · Fixtures y preparación de estado 5 clases

Fixtures como sustituto de setUp
Ámbitos: función, módulo y sesión
Ficheros y directorios temporales
conftest y fixtures compartidas
Limpieza garantizada tras cada prueba

Módulo 4 · Aislar el mundo exterior 5 clases

Dobles de prueba: qué sustituir y qué no
monkeypatch para variables de entorno y funciones
Simular una llamada HTTP externa
Base de datos de prueba frente a doble
Pruebas que no dependen del reloj

Módulo 5 · Desarrollo dirigido por pruebas 5 clases

El ciclo rojo-verde-refactor
Escribir la prueba antes que el código
Añadir una funcionalidad completa guiada por pruebas
Refactorizar con la red de seguridad puesta
Cuándo el TDD estorba y cuándo ayuda

Módulo 6 · Cobertura y automatización 5 clases

Medir cobertura y leer el informe
Qué no dice la cobertura sobre la calidad
Ejecución automática en cada cambio
Pruebas lentas: marcado y separación
Integración con el repositorio del equipo

Módulo 7 · Proyecto de cierre 4 clases

Cubrir con pruebas un módulo heredado sin cobertura
Reproducir un fallo reportado con una prueba
Corrección y confirmación de la regresión cubierta
Revisión de la batería final y criterios de mantenimiento

Requisitos

Experiencia sólida en Python con clases, módulos y excepciones
Haber trabajado con un repositorio Git y con la terminal
Tener un proyecto propio o participar en uno donde aplicar lo aprendido

Descripción

El coste de un proyecto sin pruebas no aparece al escribirlo, aparece al cambiarlo. Cada modificación obliga a comprobar a mano lo que ya funcionaba, y como eso es tedioso se deja de hacer. Al cabo de unos meses nadie sabe si una corrección ha roto algo lejano, y el equipo empieza a evitar tocar el código en lugar de mejorarlo.

El curso trabaja con pytest sobre un proyecto real que tiene ficheros, una base de datos y una llamada externa: exactamente los tres puntos donde las pruebas suelen atascarse. Se practican fixtures, parametrización, dobles de prueba, cobertura y ejecución automática en cada envío. La segunda parte introduce el desarrollo dirigido por pruebas escribiendo primero la prueba que falla y después el código que la satisface.

El resultado es una batería de pruebas que se ejecuta en segundos y avisa en cuanto algo se rompe, incluso en una parte del código que nadie ha tocado. A partir de ahí se puede refactorizar con confianza, aceptar contribuciones externas con un criterio objetivo de aceptación y sostener un proyecto que varias personas modifican a la vez.

¿Para quién es este curso?

Desarrolladores que mantienen código en producción y temen que un cambio rompa algo remoto
Equipos pequeños que aceptan contribuciones y necesitan un criterio objetivo de aceptación
Programadores que quieren refactorizar un proyecto heredado sin trabajar a ciegas