Integration Testing Es la Parte que la AI No Puede Saltarse Por Ti

La plataforma funciona. End-to-end, todo el camino: log in, navegar el lobby, sentarse en una mesa, ver los asientos, abrir el diálogo de buy-in, observar una mano.

Llegar aquí tomó cuatro posts. Un bug de routing, un mismatch de formato de datos, un auth guard roto, un entorno de desarrollo que estaba ignorando silenciosamente los cambios de código.

También tomó integration testing. De lo cual trata este post.

Cómo Se Vio la Fase de Testing

Probamos usando Playwright -- una herramienta de automatización de browser que escribe scripts de interacciones reales del navegador y verifica los resultados. Browser real. Requests reales. UI renderizada real.

La sesión: log in con credenciales de test, llegar al lobby, confirmar que las cards de la tabla se renderizan a la altura correcta, navegar a una mesa, confirmar que la barra de header aparece con un botón de lobby y un botón de help, confirmar que el seat picker renderiza todos los asientos abiertos.

Cada paso falló en la primera corrida.

Las table cards medían 572 pixels de alto porque CSS Grid aplica align-items: stretch por defecto cuando solo hay un item en la fila. Nadie especificó esto. Nadie lo rompió intencionalmente. Es lo que CSS hace.

Navegar a una mesa enviaba al browser a un loop de redirect. El auth guard estaba revisando un valor de contexto del router que nunca era poblado.

Estos no son modos de falla específicos de AI. Son la clase de bugs que solo aparecen cuando el stack completo corre junto. Habrían aparecido también en código escrito por humanos. La fase de testing los atrapa de cualquier manera.

Por Qué el Código Generado por AI Aún Necesita Esto

Existe una versión del desarrollo asistido por AI que trata el testing como opcional. El razonamiento: el spec es correcto, el agente implementa el spec, por lo tanto la implementación es correcta.

Este razonamiento falla en la capa de integración.

Los componentes individuales pueden cada uno implementar su spec correctamente y aún así fallar al comunicarse entre sí. El spec describe comportamiento en aislamiento. El integration testing verifica comportamiento en composición. Una especificación de 100 páginas que cubre cada dominio del sistema aún no describe cada default de CSS Grid y cada orden de inicialización del context del router.

Correr la cosa es la única forma de ver cómo se ve correr la cosa.

Lo Que el Humano Aún Hace

Cada falla en la sesión de testing fue identificada por una persona observando un browser. La card del lobby se estiraba a altura completa -- esa observación es visual, no logueada. La mesa cargaba en blanco -- eso requirió ver los network requests y notar el 404. El loop de redirect fue rastreado siguiendo el historial de navegación del browser.

Estas observaciones suceden antes de que la AI se involucre en el diagnóstico. El agente puede rastrear un bug que has descrito. La descripción requiere un humano que entienda cómo se supone que se ve el comportamiento.

Esto no es una limitación de la metodología. Es la metodología funcionando correctamente. El humano define el sistema, verifica el output, y escala fallas. El agente diagnostica y arregla. Esa división se sostiene durante toda la fase de testing.

Donde Estamos Ahora

El entorno de desarrollo pasa el end-to-end testing. La plataforma está operacionalmente lista. Entre ahora y la beta abierta: validación final en staging, la integración del card payment processor, y enforcement de geofencing.

La fase de testing no terminó. Subió en el stack.

El salty.poker changelog se actualiza mientras enviamos. Síguelo si quieres rastrear el build en tiempo real.

Para la serie completa sobre la metodología de ingeniería -- cómo el spec maneja las sesiones, cómo se ve el rol del arquitecto a través de la fase de testing, y lo que casi 30 años construyendo software te enseñan sobre iteración -- esa serie corre en paralelo en The Salty Korean.

Stay salty.