unittest cumple, pero arrastra ceremonia: heredar de TestCase, el self. omnipresente, veinte métodos assert* que memorizar. La comunidad Python convergió hace años en una alternativa que reduce un test a su esencia — una función y un assert — sin perder ninguna potencia: pytest. En esta lección reescribirás la suite de Papyrus en estilo pytest, descubrirás las fixtures (parientes directas de tus generadores de 08-03), probarás ficheros sin tocar los datos reales gracias a tmp_path y parametrizarás los cuatro precios de socio canónicos en tres líneas.

1. Instalación en el venv y primer test
2. assert desnudo con superpoderes: la introspección
3. La misma suite, reescrita: unittest vs pytest
4. Excepciones con pytest.raises y floats con pytest.approx
5. Fixtures: el setUp hecho función (y con yield)
6. tmp_path: probar ficheros sin tocar datos/
7. Parametrización con @pytest.mark.parametrize
8. Ejecutar: pytest -v, -k y compañía
9. El siguiente escalón de madurez: unittest.mock (solo el mapa)

pytest no está en la biblioteca estándar: se instala con pip dentro del venv del proyecto, exactamente como aprendiste en el módulo 1 (y conviene congelarlo en tus dependencias):

Un test pytest es una función normal cuyo nombre empieza por test_, en un fichero test_*.py. Sin clases, sin herencia, sin self:

Ejecuta pytest en la raíz del proyecto y él solo descubre tests/, los ficheros test_*.py y las funciones test_* (también entiende clases TestCase, así que tu suite de 09-02 corre sin cambios bajo pytest — la migración puede ser gradual).

En 09-01 dijimos que el assert a pelo daba mensajes pobres, y en 09-02 que assertEqual existía para mostrarte ambos valores. pytest disuelve el dilema: reescribe los assert de tus tests (introspección de aserciones) para que, al fallar, muestren cada subexpresión evaluada. Si el bug de doble redondeo de Ana volviera:

Obtienes el valor real (12.36), el esperado (12.35) y hasta el __repr__ del Libro implicado (cortesía de la dataclass de M5) — sin haber escrito ningún mensaje. Por eso en pytest el assert desnudo no es una limitación: es la interfaz.

La clase TestVender de la lección anterior, traducida:

La comparación, cara a cara:

¿Por qué la comunidad prefiere pytest? Menos ruido por test (lo importante ocupa todo el espacio), mensajes de fallo muy superiores, fixtures componibles y un ecosistema de plugins gigante. unittest sigue siendo valioso — sin dependencias, ubicuo en código corporativo antiguo — y todo lo aprendido en 09-02 (AAA, aislamiento, nombres descriptivos) se traslada intacto: solo cambia la sintaxis.

pytest.raises es, de nuevo, un context manager (08-04 sigue rindiendo). Su extra respecto a assertRaises es el parámetro match=, una expresión regular que debe encontrarse en el mensaje de la excepción:

match="La Odisea" garantiza que el mensaje menciona el título — probamos no solo que falla, sino que falla explicándose bien, que era la razón de ser de nuestra jerarquía ErrorPapyrus.

pytest.approx resuelve los floats con una sintaxis que se lee como matemática:

Para importes monetarios, abs=0.01 (medio camino entre céntimos) es una elección explícita y clara.

La fixture catalogo de arriba merece una segunda mirada. Se declara con @pytest.fixture (¡un decorador, 08-02!) y los tests la reciben pidiéndola como parámetro: pytest ve que el test declara catalogo, busca la fixture de ese nombre, la ejecuta y le inyecta el resultado. Cada test recibe un catálogo recién construido — el aislamiento de setUp, sin clase.

¿Y el tearDown? Aquí pytest conecta con tus generadores de 08-03: una fixture con yield hace el montaje antes del yield y la limpieza después:

Es literalmente el patrón del generador: el código se pausa en el yield, el test consume el valor, y al terminar el test pytest reanuda la función para ejecutar la limpieza. Setup y teardown en una sola función, con las variables compartidas de forma natural. Si varias suites necesitan la misma fixture, se mueve a un fichero especial tests/conftest.py y pytest la hace visible a todos los tests sin importarla.

cargar_catalogo(ruta: Path) -> dict[str, Libro] y cierre_de_caja(ruta_ventas: Path) -> float trabajan con ficheros (M6). Probarlas contra datos/catalogo.csv real violaría la repetibilidad: el test fallaría el día que Ana añada un libro. pytest regala la fixture tmp_path: un Path (¡el pathlib de M6!) a un directorio temporal único por test, que pytest crea y destruye por ti.

Fíjate en lo que acabamos de conseguir: probamos el comportamiento tolerante a filas corruptas de cierre_de_caja — imposible de verificar contra el ventas.csv real sin ensuciarlo — en un directorio desechable, con el mismo write_text/encoding="utf-8" que dominas desde M6. El test es rápido, aislado y repetible en el portátil de cualquiera de los socios.

El ejercicio 2 de 09-02 (los cuatro precios de socio, con bucle y subTest) tiene en pytest una forma canónica:

El decorador genera cuatro tests independientes (uno por tupla): pytest -v los lista como test_precio_socio_canonico[La Odisea-12.5-12.35], etc., y si fallan dos, ves los dos. Añadir un quinto libro al catálogo canónico será añadir una línea a la lista. Datos y lógica, separados.

El ciclo de trabajo natural: pytest completo tras cada cambio; -k o --lf mientras persigues un fallo concreto; -v cuando quieres leer la suite como la lista de contratos que es.

Sé honesto contigo: hay cosas que esta lección no resuelve. ¿Cómo pruebas una función que llama a una API por la red, consulta la hora actual o depende de algo lento o no determinista? La respuesta profesional son los dobles de prueba (mocks): objetos falsos que sustituyen a la dependencia real durante el test. Python los trae en unittest.mock (compatible con pytest). Es el siguiente escalón en la madurez de un tester, y asoma de forma natural cuando Papyrus hable con servicios externos — cosa que empezará a ocurrir en el módulo 10, con la web. Por ahora, quédate con el nombre y con esta regla: si tu función es difícil de probar porque depende de medio mundo, suele ser el diseño el que pide desacoplarse, no el test el que pide magia.

• Instalar pytest fuera del venv (o con el venv desactivado): luego pytest "no existe" o ejecuta contra otro Python. Comprueba con pip list dentro del venv (M1).
• Olvidar pedir la fixture como parámetro: si escribes def test_x(): y usas catalogo dentro, obtienes NameError. La inyección ocurre solo si el parámetro se llama exactamente como la fixture.
• Mutar una fixture creyendo que es compartida (o al revés): por defecto cada test recibe una fixture nueva (scope="function"). Si cambias a scope="module" por velocidad, los tests vuelven a compartir estado mutable — el fantasma de M4. Con datos mutables, quédate en el scope por defecto.
• pytest.raises(Exception): capturar la excepción más genérica hace pasar el test aunque salte un error distinto del esperado. Captura la clase concreta (StockInsuficienteError), como te enseñó el módulo 7 con except.
• Construir rutas a mano en vez de usar tmp_path: Path("test_tmp.csv") deja basura en el proyecto y colisiona entre tests. tmp_path es único por test y se limpia solo.
• Consejo: ejecuta pytest antes de empezar a cambiar código, no solo después. Saber que partías de verde convierte cualquier rojo posterior en información pura.

Reescribe en estilo pytest los tres tests de reponer del ejercicio 1 de 09-02, usando la fixture catalogo (solo necesitas Hamlet) y pytest.raises con match= en el caso del título inexistente (el mensaje de LibroNoEncontradoError contiene el título).

Escribe un test parametrizado test_precio_sin_socio con los cuatro libros canónicos y sus precios finales sin descuento (calcula: base × 1.04, redondeado a 2 decimales) usando pytest.approx.

Usando tmp_path, escribe test_cierre_de_caja_fichero_vacio_devuelve_cero: crea un ventas.csv que contenga solo la cabecera fecha,titulo,importe y comprueba que cierre_de_caja devuelve 0.0.

Ejercicio 1

Ejercicio 2 — los esperados: 12.50×1.04=13.00; 9.95×1.04=10.348→10.35; 15.90×1.04=16.536→16.54; 21.00×1.04=21.84.

Ejercicio 3

Un fichero con solo cabecera es un límite clásico (la familia "límites" de 09-01): cero filas que sumar no debe ser un error, sino 0.0.

La suite de Papyrus ha adelgazado y ganado músculo a la vez: tests que son funciones, assert desnudo con introspección que muestra los valores al fallar, pytest.raises(..., match=) para las excepciones de M7, pytest.approx para los precios, fixtures que inyectan un catálogo fresco (y hacen setup+teardown con un yield, como tus generadores), tmp_path para probar cargar_catalogo y cierre_de_caja sin rozar datos/, y parametrize fijando los cuatro precios de socio canónicos en una tabla. Hasta ahora, sin embargo, hemos seguido siempre el mismo orden: primero el código, después sus tests. En la próxima lección invertiremos la flecha: escribir el test antes que el código — rojo, verde, refactor — y descubrir que los tests no solo verifican el diseño: lo producen. Lo haremos con una pieza nueva de Papyrus que Ana lleva semanas pidiendo: los cupones de descuento.