Papyrus Online funciona — o eso parece cuando lo pruebas a mano. Pero "lo probé a mano el martes" no es verificación: es una anécdota. Esta lección convierte los criterios de aceptación de 12-01 en una suite de tests ejecutable, la que te permite tocar cualquier pieza del sistema y saber en veinte segundos si has roto algo. Aplicaremos la pirámide de M9 al proyecto completo — qué se prueba en cada nivel y con qué herramienta —, escribiremos el test de integración que recorre todo el flujo (vender → persistir → releer → cuadrar caja), probaremos la interfaz con su cliente de pruebas, y aprenderemos a depurar a través de las capas cuando un test diga que no. Al final: la checklist de calidad que decide si el proyecto está listo para entregarse.

1. La pirámide aplicada a Papyrus Online
2. Datos de prueba vs datos reales: las fixtures canónicas
3. La suite mínima exigible (criterios → tests)
4. El test de integración del flujo completo
5. Probar la interfaz: test client de Flask / Client de Django
6. Regresiones: cada bug deja su test
7. Depurar el sistema integrado
8. Checklist final de calidad

En 09-01 la pirámide era teoría; ahora tiene nombres y apellidos. Cada nivel prueba una cosa distinta, con una herramienta distinta, y en la proporción correcta (muchos abajo, pocos arriba):

La regla de reparto: si un comportamiento puede probarse en un nivel inferior, se prueba ahí. El redondeo de 12.35 se verifica en el nivel unitario, no lanzando peticiones HTTP; el endpoint solo verifica que traduce bien (JSON correcto, código correcto), porque el fondo ya está probado más abajo. Probar el redondeo por HTTP funciona, pero es lento, frágil y, cuando falla, no te dice dónde está el bug.

Regla absoluta: los tests jamás tocan datos/. Un test que escribe en tu catálogo real es una bomba: corrompe tus datos o, peor, pasa o falla según lo que vendiste ayer. Todos los tests trabajan sobre tmp_path (M9) con las fixtures canónicas — los cuatro libros de siempre, precisamente porque llevas once módulos conociendo sus números de memoria:

Aquí cobra sentido la decisión de diseño de 12-02: como el servicio recibe los repositorios ya construidos, los tests le inyectan repositorios de tmp_path sin tocar una línea del código de producción. Si tu servicio hubiera abierto "datos/catalogo.json" a pelo, esta lección sería imposible. El código fácil de probar y el código bien diseñado son el mismo código.

Los criterios de aceptación de 12-01, uno a uno, convertidos en tests con nombre. Esta tabla es tu RNF1: la suite está completa cuando cada fila existe y pasa:

Con las parametrizaciones, esto suma unos 25 tests. No es un número mágico: es la traducción literal del contrato de 12-01. Si mañana añades un requisito, su fila aparece aquí antes que su código — eso era TDD (09-03) y este proyecto es el mejor sitio para practicarlo.

El test más valioso del proyecto: recorre las cuatro capas de datos (servicio → disco → releer → agregar) y comprueba que la historia completa cuadra. Completo y comentado:

El detalle que lo hace un test de integración de verdad está en el paso 2: la instancia nueva. Si reutilizas el servicio original, el test puede pasar aunque guardar() esté rota, porque el objeto recuerda el stock en memoria. Releer desde disco es lo que demuestra RF4.

Itinerario A — test client de Flask (10-03). Para inyectar el tmp_path necesitarás el patrón app factory: una función crear_app(servicio) en lugar de montar el servicio global al importar. Es un refactor de diez minutos que vuelve a demostrar la regla: probar mejora el diseño.

Itinerario B — Client de Django (10-05), donde TestCase te da una base de datos limpia por test (su equivalente del tmp_path):

Fíjate en qué verifican estos tests: la traducción, no el negocio. Que el 409 sea 409, que el JSON traiga el importe, que el form re-muestre el error. El cálculo del 18.67 ya quedó demostrado dos niveles más abajo.

Durante 12-03 encontraste bugs (todos los encontramos). La regla de 09-05, ahora como disciplina de proyecto: ningún bug se cierra sin su test. El flujo: bug detectado → escribes el test que lo reproduce (falla, rojo) → arreglas → el test pasa (verde) → el test se queda en la suite para siempre. Ese test vale más que diez tests inventados: protege un punto donde tu sistema demostró que sabía romperse. Anota en DECISIONES.md cada regresión con una línea ("cierre_de_caja sumaba strings — test_cierre_convierte_importes"): en 12-05, esa lista será oro para tu retrospectiva.

Cuando un test (o el uso real) falla en el sistema completo, el bug puede estar en cualquiera de las cuatro capas. Tres técnicas, por orden:

• Leer el traceback A TRAVÉS de las capas. Un traceback del sistema integrado es largo: líneas de Flask/Django, líneas tuyas de app.py, de servicios.py, de repositorios.py. Recórrelo de abajo arriba y localiza la última línea tuya: esa es la capa donde estalló. Pero cuidado: donde estalla no siempre es donde se rompió — un KeyError en el servicio puede ser un JSON mal guardado por el repositorio hace tres ventas. El traceback te da la capa de la explosión; la causa puede vivir una capa más abajo.
• El log como testigo entre capas. papyrus.log registra qué hizo cada capa y en qué orden (RF7 ya no es un requisito burocrático: es tu caja negra). ¿El endpoint devolvió 500? Mira el log: si la última línea es el INFO de una venta, el fallo fue después de vender — en el guardado o en la serialización de la respuesta. Acabas de descartar dos capas sin abrir el depurador.
• pdb en el punto de integración. breakpoint() justo donde una capa entrega a la siguiente (la llamada del endpoint al servicio, la del servicio al repositorio) e inspecciona el paquete que cruza la frontera: p datos, p type(fila["unidades"]). Como decía 12-03: la mayoría de los bugs de integración son "creía que me pasabas X y era Y" — y la frontera es donde se ve.

Antes de declarar el proyecto "entregable", pásale esta lista. No es burocracia: es la diferencia entre creer que está bien y saberlo.

• [ ] RF1: alta duplicada rechazada; baja + consulta → no encontrado. Test en verde.
• [ ] RF2: los 8 importes canónicos exactos (parametrizado); socio falso rechazado.
• [ ] RF3: venta sin stock no modifica nada (¡verifica el stock después del error!); 18.67 con socio+cupón; cupón falso rechazado.
• [ ] RF4: el test de integración pasa; matar el proceso durante un guardado no corrompe el JSON.
• [ ] RF5: todas las rutas/vistas con su test de código de estado.
• [ ] RF6: informe sobre ventas_2026.csv → 520 unidades, sábado 130, PNG generado.
• [ ] RF7: caplog (o el fichero) confirma el WARNING en cada rechazo.
• [ ] RNF1: pytest → todo verde, ~25 tests, ninguno tocando datos/ real.
• [ ] RNF2: cero funciones públicas del paquete sin type hints.
• [ ] RNF3: cero except Exception genéricos sin justificación escrita.
• [ ] RNF4: el README existe y otra persona podría arrancar el proyecto con él (se verifica en 12-05).

• Probar el negocio por HTTP. Si test_api_... verifica redondeos, tienes la pirámide invertida: lenta, frágil y con diagnósticos pobres. El endpoint prueba la traducción; el dominio, el fondo.
• Tests que comparten estado. El síntoma clásico: pasan en solitario, fallan en suite (o según el orden). Causa: escriben en el mismo sitio. La fixture rutas crea un mundo nuevo por test; úsala siempre.
• Comparar floats a lo bravo. assert importe == 18.67 funciona aquí porque redondeamos a 2 decimales en un único punto (12-03). Si un assert de importes te falla por 0.0000001, no "arregles el test con pytest.approx": tienes un redondeo de más o de menos en el código. approx es para matemáticas continuas, no para dinero redondeado.
• Borrar el test de un bug arreglado ("ya no falla, sobra"). Es exactamente al revés: es el único test con un fallo real demostrado en su historial.
• Depurar añadiendo print por todas partes. Ya tienes tres herramientas mejores y ordenadas: traceback (¿qué capa?), log (¿qué pasó antes?), pdb (¿qué cruza la frontera?). Los print sueltos acaban olvidados en el código — el log es un print con contrato.

1. Hito de proyecto — la suite completa. Implementa las 12 filas de la suite mínima (con sus parametrizaciones). Verificación: pytest -v en verde, y el nombre de cada test dice qué RF cubre sin abrir el fichero.
2. Hito de proyecto — el test del guardado atómico. Escribe test_guardar_es_atomico: provoca un fallo a mitad de guardar (pista: pasa un catálogo con un objeto no serializable, que hará estallar a json.dump) y comprueba que el fichero original sigue intacto y cargable. Este test justifica todo el diseño del os.replace de 12-03.
3. Hito de proyecto — tu regresión. Elige el bug más doloroso que encontraste en 12-03, escribe su test de regresión con un nombre que cuente la historia, y añade la línea correspondiente a DECISIONES.md.

1. Autocomprobación en lugar de solución: ejecuta pytest --collect-only y compara la lista con la tabla de la suite mínima; cada fila debe tener al menos un test recogido. Si test_informe_... tarda varios segundos, está bien: es el precio de pandas + PNG, y por eso hay uno, no veinte.
2. Orientativa: catalogo_roto = dict(catalogo); catalogo_roto["X"] = object() y with pytest.raises(TypeError): repo.guardar(catalogo_roto); después, repo.cargar() debe devolver el catálogo original sin error. Si tu guardar escribía directamente sobre self._ruta, este test te lo dirá con un JSONDecodeError — y acabas de entender, con un fallo controlado, para qué existía el fichero temporal.
3. Sin solución única. Criterio de calidad del nombre: alguien que no vivió el bug debe entender qué protege — test_cierre_de_caja_convierte_importes_a_float sí; test_bug_arreglado_2 no.

Papyrus Online ya no es código que parece funcionar: es un sistema verificado. La pirámide dejó de ser un dibujo — dominio con tests unitarios a milisegundos, servicio sobre tmp_path, un test de integración que recorre vender → persistir → releer → cuadrar, y una interfaz cuya traducción HTTP está demostrada con su cliente de pruebas. Los criterios de 12-01 son ahora 25 tests con nombre, cada bug del desarrollo dejó su regresión, y sabes depurar a través de las capas con traceback, log y pdb en las fronteras. La checklist final está marcada: el proyecto está terminado. Pero terminado no es lo mismo que entregado: falta que otra persona pueda instalarlo, entenderlo y verlo funcionar — y falta que tú puedas contarlo. Documentación, demo, informe final y la mirada atrás sobre todo el camino: eso es la última lección del curso.