Testing, logging y debugging

Hay una etapa en la que tu programa funciona y aun así no sabes si seguirá funcionando mañana. Cambias una función para arreglar un caso, rompes otro sin darte cuenta, y lo descubres cuando el informe ya se envió. Las tres herramientas de esta lección existen para que eso deje de ser una sorpresa: pruebas para comprobar, registros para observar, y un depurador para mirar dentro cuando algo no cuadra.

Antes de entrar, conviene ordenar el vocabulario, porque se usa mal. Un error de sintaxis impide que el archivo se ejecute. Una excepción ocurre durante la ejecución y, si no la atrapas, termina el programa. Un fallo lógico es el peor: el programa termina sin errores y devuelve un resultado incorrecto.

¿Qué es una prueba y qué es un registro?

Una prueba es código que ejecuta tu código y comprueba un resultado esperado. Si el resultado no coincide, falla de forma visible y con la línea exacta. En Python la forma mínima es assert condicion, que lanza AssertionError cuando la condición es falsa.

Un registro (log) es una línea de texto que tu programa emite para contar lo que hace: cuántas filas leyó, qué usuario pidió el informe, qué error se capturó. Se diferencia de print en que tiene nivel, origen y formato configurables, y en que puede apagarse sin borrar código.

El debugging es la tercera pata: inspeccionar el estado de un programa detenido. print sirve para una duda puntual; un depurador te deja parar en una línea, ver todas las variables y avanzar paso a paso sin modificar el archivo.

¿Para qué sirve todo esto?

• Detectar regresiones: al cambiar una función, las pruebas avisan si rompiste un comportamiento anterior.
• Documentar intención: un test que dice aplicar_descuento(100, 0.10) == 90.0 explica la regla mejor que un comentario.
• Diagnosticar en producción: los logs muestran la secuencia de hechos cuando no puedes reproducir el fallo en tu máquina.
• Medir la confianza: la cobertura indica qué líneas nunca se ejecutaron en las pruebas, no si las que sí corren están bien.
• Ahorrar tiempo: un breakpoint() bien puesto encuentra en un minuto lo que veinte print no encuentran en una hora.

¿Cómo funciona por dentro?

assert es una instrucción, no una función: evalúa la expresión y, si es falsa, lanza AssertionError con el mensaje opcional. Python puede eliminar todos los assert cuando se ejecuta con python3 -O (modo optimizado). Por eso un assert nunca debe validar datos que vienen del usuario ni sustituir a un if ... raise.

pytest descubre pruebas por convención: archivos test_*.py o *_test.py, funciones que empiezan por test_, clases que empiezan por Test. No hace falta heredar de nada ni registrar cada test. Además reescribe los assert para que un fallo muestre los valores intermedios, y ofrece fixtures (datos preparados y reutilizables) y parametrize (el mismo test con varias entradas).

El módulo logging organiza el trabajo en tres piezas: un logger que recibe los mensajes, uno o varios handlers que deciden a dónde van (consola, archivo), y un formatter que define el texto. Los mensajes suben por la jerarquía de loggers hasta el logger raíz, que es el configurado por basicConfig. Cada mensaje tiene un nivel numérico y solo se emite si alcanza el nivel configurado.

Sintaxis: assert, pytest y logging

1234567891011121314

# 1. Comprobación simple
assert 2 + 2 == 4
assert 10 > 3, "10 debería ser mayor que 3"

# 2. Prueba de pytest (archivo test_suma.py)
# def test_suma():
#     assert sumar(2, 3) == 5

# 3. Registro con nivel y formato
import logging

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(message)s")
log = logging.getLogger(__name__)
log.info("proceso iniciado")

El mensaje de un assert se escribe después de una coma y solo se evalúa si la condición falla. En pytest, cada archivo de prueba importa lo que va a probar; no hay un main ni una lista de tests que mantener. En logging, getLogger(__name__) da al logger el nombre del módulo, así el formato puede decir de dónde viene cada línea.

Ejemplo básico: comprobar con assert

Antes de instalar nada puedes verificar una función con asserts. Este ejemplo comprueba el caso normal y el caso de una sola nota, y además define qué debe ocurrir con una lista vacía.

12345678

def promedio(notas):
    if not notas:
        raise ValueError("la lista de notas está vacía")
    return sum(notas) / len(notas)

assert promedio([10, 20]) == 15.0
assert promedio([20]) == 20.0
print("todas las comprobaciones pasan")

Si cambias el 20 por 30 en la segunda comprobación, el programa se detiene con AssertionError y la línea exacta. Ese fallo temprano es la virtud del assert: el error aparece donde se produce, no tres pasos después cuando el resultado ya se guardó. La validación de la lista vacía, en cambio, es un raise de verdad: seguiría activa con -O.

Ejemplo intermedio: una prueba de pytest con fixture y parámetros

Este es el aspecto de un proyecto real. precios.py contiene la lógica; test_precios.py contiene las pruebas. Las fixtures preparan datos compartidos y parametrize repite el mismo test con tres entradas sin copiar y pegar. Instala pytest dentro del entorno virtual con pip install pytest.

1234

def aplicar_descuento(precio: float, descuento: float) -> float:
    if not 0 <= descuento < 1:
        raise ValueError("el descuento debe estar entre 0 y 1")
    return precio * (1 - descuento)

12345678910111213141516171819202122232425

import pytest

from precios import aplicar_descuento


@pytest.fixture
def catalogo():
    return {"teclado": 120.0, "mouse": 45.0}


@pytest.mark.parametrize(
    "precio, esperado",
    [(100.0, 90.0), (45.0, 40.5), (0.0, 0.0)],
)
def test_descuento_diez_por_ciento(precio, esperado):
    assert aplicar_descuento(precio, 0.10) == pytest.approx(esperado)


def test_catalogo_tiene_dos_productos(catalogo):
    assert len(catalogo) == 2


def test_descuento_invalido():
    with pytest.raises(ValueError):
        aplicar_descuento(100.0, 1.5)

Con pytest -q obtienes 5 passed: tres casos del test parametrizado, el del catálogo y el del error esperado. pytest.approx compara flotantes con tolerancia, porque operaciones como 0.1 + 0.2 no dan exactamente 0.3 en binario. La fixture catalogo se inyecta por el nombre del parámetro, y pytest.raises comprueba que el error se lanza en lugar de dejar que tumbe la suite.

Caso práctico: instrumentar un proceso ETL

En un proceso que carga, limpia y transforma datos, los logs son la única evidencia que tendrás a las tres de la mañana. La clave es registrar hechos con nivel adecuado y no convertir el registro en una novela: una línea por hito y una por anomalía.

1234567891011121314151617181920212223242526

import logging

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(name)s: %(message)s")
log = logging.getLogger("etl")


def cargar(filas):
    if not filas:
        raise ValueError("no hay filas para procesar")
    log.info("cargadas %d filas", len(filas))
    return filas


def limpiar(filas):
    validas = [fila for fila in filas if fila.get("precio")]
    descartadas = len(filas) - len(validas)
    if descartadas:
        log.warning("filas descartadas: %d", descartadas)
    return validas


try:
    datos = cargar([{"precio": 10}, {"precio": None}, {"precio": 25}])
    print(limpiar(datos))
except ValueError as error:
    log.error("ETL abortado: %s", error)

La salida es INFO etl: cargadas 3 filas, WARNING etl: filas descartadas: 1 y la lista con dos diccionarios. Fíjate en los %d y %s: pasar los valores como argumentos retrasa el formateo hasta que el mensaje se emite, y evita construir cadenas que luego se descartan por nivel. Si mañana bajas el nivel a DEBUG, no cambias ni una línea del código.

Visualización: qué mensajes pasan el filtro

Recorre los pasos y observa el filtro de nivel. Los mensajes DEBUG e INFO se descartan antes de formatearse; solo WARNING y ERROR llegan al handler de la consola.

—

Errores comunes

123

x = 3
assert (x == 4, "x debería ser 4")
print("sigue")

123

x = 3
assert x == 4, "x debería ser 4"
print("no se alcanza")

123456

python3 -m pdb factura.py
# (Pdb) b factura.py:8     ← punto de parada en la línea 8
# (Pdb) c                  ← continúa hasta allí
# (Pdb) p cantidad         ← muestra el valor actual
# (Pdb) n                  ← ejecuta la línea siguiente
# (Pdb) q                  ← termina la sesión

Buenas prácticas

• Prueba el caso normal, el límite y el error esperado; los tres suelen revelar fallos distintos.
• Un test debe poder ejecutarse solo y en cualquier orden: no dependas del test anterior.
• Nombra los tests por el comportamiento (test_descuento_invalido_lanza_error), no por el método.
• No uses assert para validar entradas de usuario: con -O desaparecen. Usa if ... raise ValueError.
• Registra hechos, no emociones: filas descartadas: 3 sirve; algo va mal no.
• Usa parámetros %s/%d en logging y deja DEBUG para el detalle que solo activas al investigar.
• Ejecuta pytest --cov=paquete para ver qué quedó sin probar, y revisa las líneas, no el porcentaje.

Ejercicios

import logging

logging.basicConfig(level=logging., format="%(levelname)s %(message)s")
log = logging.getLogger()

log.("inicio del proceso")

Soluciones explicadas

En el primer ejercicio, la decisión importante es probar el límite: 17 y 18 son los valores que separan los dos comportamientos, y un test con solo 20 no habría detectado un > escrito por error en lugar de >=. Añadir 65 comprueba que el caso normal sigue funcionando. La prueba del tipo incorrecto no busca que el programa sea elegante, sino fijar por escrito qué ocurre con una entrada que no es un número.

En el segundo, el redondeo no es un detalle cosmético: 3 * 19.9 da 59.699999999999996 en coma flotante, y un total de factura con esa cola es inaceptable. round(..., 2) lo resuelve para el valor devuelto, y %.2f hace lo mismo en el log. También es deliberado que el except esté fuera de la función: la función informa del problema lanzando, y la capa que decide continuar o abortar es quien llama.

La regla que une ambos ejercicios: una prueba comprueba comportamiento observable, un log registra lo que ya ocurrió y un depurador examina lo que está ocurriendo. Mezclarlos produce código difícil de probar: si la función imprime en vez de devolver, el test tiene que capturar la salida; si el log reemplaza al error, nadie se entera del fallo.

Resumen

• Un error de sintaxis impide ejecutar; una excepción ocurre en ejecución; un fallo lógico produce un resultado incorrecto sin avisar.
• assert comprueba una condición y lanza AssertionError; con -O se elimina, así que no valida entradas reales.
• pytest descubre test_*.py y funciones test_*, y reescribe los assert para mostrar los valores del fallo.
• Las fixtures preparan datos reutilizables y parametrize ejecuta el mismo test con varias entradas.
• La cobertura mide líneas ejecutadas, no comportamientos comprobados.
• logging filtra por nivel: DEBUG 10, INFO 20, WARNING 30, ERROR 40, CRITICAL 50.
• breakpoint() abre pdb: p inspecciona, n avanza, c continúa y q sale.

Evaluación