Por qué una conexión MCP para testing de aplicaciones web supera a leer el código
Una lectura estática de una aplicación web te dice qué pretende el código. No te dice qué hace el navegador con él. La distancia entre ambas cosas es donde vive la mayoría de los defectos visibles para el usuario, y se amplía a medida que más código proviene de un agente que nunca ha visto la app renderizarse.
Lo que se detecta y la revisión de código no
Estado que sobrevive
Un modal deja bloqueado el scroll; un filtro persiste en un contexto donde no tiene sentido.
Solo se ve en la segunda interacción, nunca en un diff.
Render antes que los datos
La página se pinta, el fetch se resuelve y nada se vuelve a renderizar.
Se reproduce de forma fiable usando la app; fuera de ahí es prácticamente invisible.
La segunda cuenta
Supuestos de propiedad y visibilidad que se cumplen en la sesión de quien desarrolla y en la de nadie más.
Desarrollo local
El trabajo en aplicaciones web ocurre en localhost mucho antes de que se despliegue nada, y una verificación que solo llega a una URL pública llega demasiado tarde para cambiar lo que construyes. Los destinos locales están soportados, así que la verificación está disponible mientras todavía trabajas y no solo después de un despliegue. El funcionamiento actual está en la documentación.
Cómo configurarlo
El servidor MCP es un paquete distinto del CLI, publicado como @testsprite/testsprite-mcp. Lo agregas a la configuración MCP de tu editor con una API key del dashboard, y el editor lo ejecuta como un subproceso. Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot y Trae lo soportan; la configuración exacta varía según el cliente y está en la documentación de instalación de MCP.
Qué cubrir primero
Registrarse, cerrar sesión, iniciar sesión. El fallo total más común en una aplicación web generada.
Crear algo y recargar. Separa «la pantalla se actualizó» de «el registro existe».
El flujo principal con una segunda cuenta. Detecta los supuestos de permisos incrustados en la propia sesión de quien desarrolla.
La trampa de los tres estados
Las aplicaciones web tienen algo peculiar: una misma funcionalidad puede estar en tres estados inconsistentes a la vez, y la mayoría de los errores en tiempo de ejecución son una discrepancia entre ellos.
El servidor tiene un registro. El navegador tiene una copia en memoria. Y el usuario tiene un modelo mental construido a partir de lo que vio hace un momento. Un borrado que elimina el registro y la copia en memoria pero deja la fila en pantalla produce un usuario convencido de que el borrado falló. Un guardado que actualiza la pantalla pero no el servidor produce lo contrario.
La consecuencia práctica es que una verificación que solo mira uno de los tres demuestra muy poco. Comprobar la pantalla justo después de una acción prueba la copia del navegador. Comprobar después de recargar prueba el servidor. Hacer la acción dos veces prueba si la primera dejó algo atrás. Esas tres juntas cubren la mayor parte de lo que realmente llega a los usuarios, y ninguna requiere leer el código.
Después, haz que sobreviva a la sesión
Una conexión MCP cubre el momento del cambio. La regresión necesita que esas mismas verificaciones se ejecuten haya o no alguien frente al teclado.
La GitHub App es un webhook que configuras en el dashboard de TestSprite. Escucha el evento de despliegue que tu pipeline ya produce, así que nada cambia en tu repositorio.
GitHub Actions coloca el paso dentro de tu propio workflow, configurado desde la terminal. Los comandos actuales están en el repositorio del CLI.
Lo que TestSprite comprueba y un diff no puede
Abre la aplicación en ejecución y la usa, que es la única forma de ver los tres fallos anteriores. El estado que queda después de una interacción, un render que nunca se pone al día con sus datos y un comportamiento distinto para una segunda cuenta son invisibles en el código fuente y evidentes al usar la app.
Como la conexión vive dentro del bucle del agente, la verificación ocurre como parte de hacer el cambio y no después. El agente crea el caso, lo ejecuta, lee la divergencia e itera, y tú ves el resultado en lugar de las idas y vueltas.
Lo que obtienes es un conjunto de flujos que se vuelven a verificar en cada cambio, de modo que el supuesto de permisos o el filtro obsoleto no puedan volver en silencio una vez terminada la sesión que los encontró.
¿Necesita mi código fuente?
No. Maneja la aplicación en ejecución a través de su interfaz y reporta el comportamiento. Tu agente ya tiene el código.
¿Puede probar un servidor de desarrollo local?
Sí para ejecuciones de frontend, mediante un túnel desde tu máquina. Los destinos locales solo de backend siguen necesitando una URL accesible.
¿Y los flujos que necesitan correo o pagos reales?
Usa modos de prueba y cuentas dedicadas. Todo lo que requiera un efecto real en un tercero se maneja mejor como una comprobación manual deliberada.
¿Cuántas verificaciones debería tener una aplicación web?
Empieza con las tres anteriores y luego agrega una por cada bug con el que realmente te topes. La cobertura que sigue a los fallos reales supera a la que apunta a un porcentaje.
¿Es lo mismo que el CLI?
La misma capacidad, distinto punto de entrada. MCP encaja con el trabajo dentro del editor; el CLI encaja con scripts y pipelines.
Abre la app, no te limites a leerla.
Una conexión MCP para testing de aplicaciones web permite que el agente encuentre estado residual, problemas de render antes que los datos y de segunda cuenta que ningún diff revela. Cubre primero el inicio de sesión, la persistencia y una segunda cuenta; después mantén las verificaciones en ejecución cuando la sesión termine.