Pruebas end-to-end y puntos ciegos

Un coro que suena mal con todas las voces bien

Cada voz del coro ensaya sola con auriculares y suena perfecta. El día del concierto cantan juntos y las sopranos van medio tiempo más rápido que los bajos. Ninguna voz estaba mal; el conjunto, sí.

Con el software pasa lo mismo. Un agente añade una función de exportar archivos a una aplicación de escritorio: escribe la parte visual, el puente intermedio y la capa de servicio. Las pruebas de cada parte pasan. Al pulsar el botón, la ruta del archivo viene en formato equivocado, la barra de progreso no se actualiza y exportar un archivo grande agota la memoria. Cinco defectos, ni uno detectado por las pruebas unitarias.

Los puntos ciegos de las pruebas unitarias

Una prueba unitaria comprueba una pieza aislada y finge (mock) a sus vecinas. Eso las hace rápidas y precisas, pero crea puntos ciegos sistemáticos:

Una prueba end-to-end (e2e, «de extremo a extremo») recorre el sistema real como lo haría un usuario: pulsar el botón, pasar por el puente, llegar al servicio, tocar el sistema de archivos y comprobar el archivo resultante.

Las e2e también cambian el comportamiento del agente

Hay un efecto menos obvio: cuando el agente sabe que su trabajo se juzgará con pruebas de extremo a extremo, programa distinto. Piensa en cómo conecta cada pieza con las vecinas en vez de mirar una función suelta, respeta los límites de la arquitectura y contempla las rutas de error. Es como ensayar sabiendo que cantaréis juntos.

Primero los límites, luego las e2e

Para que las pruebas e2e digan algo útil, el sistema debe tener límites claros. Si todo es un plato de espaguetis, la prueba solo dice «el plato funciona», no te dice dónde se rompió un diseño. La experiencia que recoge la lección es que las restricciones de arquitectura deben ponerse desde el primer día, porque el agente copia los patrones que ve en el repo, incluidos los malos.

Un principio útil: impide invariantes, no micro-gestiones la implementación. Por ejemplo, exige «los datos se validan en la frontera» sin dictar qué librería usar.

Ponerlas en el harness

Añade la capa e2e como requisito explícito cuando el cambio cruza componentes:

## Jerarquía de validación
- Nivel 1: pruebas unitarias (obligatorio)
- Nivel 2: pruebas de integración (obligatorio)
- Nivel 3: pruebas e2e (obligatorio si el cambio cruza componentes)
- Saltarse un nivel obligatorio = no terminado

Y convierte las reglas de arquitectura en comprobaciones ejecutables, por ejemplo una que falle si el código de la interfaz importa directamente el acceso a archivos:

grep -r "require('fs')" src/renderer/ && exit 1 || echo "OK: sin acceso directo a fs"

Los nombres de carpetas son del ejemplo de la aplicación de escritorio de la lección; adáptalos a los tuyos.