Dónde tiene que mirar el testing de desarrollo web con IA
| El estado entre pasos | Se envía un formulario y la lista que hay detrás no se actualiza. Un filtro sobrevive hasta una pantalla donde no tiene ningún sentido. |
| Los tiempos | Un render antes que los datos, o una petición que se resuelve cuando el componente ya no está. |
| El segundo usuario | Propiedad y visibilidad que se dan por hechas a partir de la sesión que lo construyó. |
Nada de esto se ve en un diff, y por eso revisar más rápido no ayuda. Sí se ve en treinta segundos de uso de la aplicación en ejecución, y por eso la comprobación tiene que ocurrir ahí.
Por qué las pruebas que escribió el agente no cierran el ciclo
Las pruebas generadas junto con la implementación comparten sus supuestos. Si el código da por hecho que un endpoint devuelve un array vacío en lugar de un 404, la prueba afirma lo mismo y pasa. Obtienes cobertura y ninguna señal independiente.
La comprobación que cierra el ciclo tiene que ejercitar el producto desplegado frente al comportamiento previsto, no frente a la idea que el código tiene de sí mismo.
Mantenerlo lo bastante rápido como para usarlo de verdad
Un paso de verificación que tarda más de lo que costó construir la funcionalidad se acabará saltando, y con razón. Tres cosas lo mantienen proporcionado: cubrir flujos en lugar de pantallas, mantener las cadenas cortas y ejecutarlo en el pull request y no en cada guardado.
Mantener el ciclo lo bastante ágil como para usarlo
Un paso de verificación que se siente lento termina saltándose, y saltárselo es racional, así que el ritmo importa tanto como la cobertura.
Tres cosas lo mantienen proporcionado. Cubre flujos en lugar de pantallas, porque un flujo es una comprobación y una pantalla son cinco. Limita cada flujo al camino más corto que aún detectaría una rotura real, que suele ser de tres o cuatro pasos y no de diez. Y ejecuta la suite amplia en el pull request, mientras mantienes una o dos comprobaciones lo bastante rápidas como para ejecutarlas durante el propio trabajo.
Esa última separación es la que se suele pasar por alto. La comprobación que ejecutas mientras construyes y la que protege el merge tienen trabajos distintos, y usar una sola suite para ambas la deja o demasiado lenta para ejecutarla a menudo o demasiado ligera para confiar en ella.
Cómo meterlo en el ciclo
La configuración inicial instala la skill de verificación en el agente de código, de modo que la comprobación ocurre donde ocurre el trabajo y no como una tarea aparte.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si prefieres no instalar nada, el dashboard hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.
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.
Lo que TestSprite verifica y el agente no puede
La aplicación desplegada, frente a lo que dijiste que debía pasar y no frente a lo que el código supone. Esa independencia es justo el punto: las pruebas escritas junto a la implementación comparten sus supuestos, así que coinciden con ella incluso donde ambas se equivocan.
La configuración inicial instala la skill de verificación en tu agente de código, de modo que la comprobación se ejecuta como parte de hacer el cambio. Los pasos son intenciones en lugar de selectores, y un fallo vuelve como un único paquete sobre el que el agente puede actuar, que es lo que mantiene el arreglo en el mismo ciclo que el cambio.
Lo que consigues es que los fallos de estado, de tiempos y de segundo usuario se detecten antes del merge y no los encuentre un usuario, sin un paso de verificación que tarde más de lo que tardó la funcionalidad.
¿Esto ralentiza el desarrollo?
Menos que la depuración que evita. La comparación no es contra coste cero, sino contra encontrar el mismo defecto después de publicar.
¿Puede el agente probar su propio trabajo?
Puede ejecutar las comprobaciones. Las comprobaciones en sí tienen que salir del comportamiento previsto y no de la implementación; si no, estás corrigiendo tu propio examen.
¿Y las pruebas que generó?
Consérvalas para tener cobertura y no las trates como verificación independiente. Coinciden con el código por construcción.
¿Cuánta cobertura antes de publicar?
Los flujos que te daría vergüenza romper, más todo lo que toque dinero o permisos. Amplía a partir de incidentes reales.
¿Funciona esto en desarrollo local?
Las ejecuciones de frontend pueden llegar a una aplicación en tu máquina a través de un túnel, así que la comprobación está disponible antes de desplegar nada.
Construir se volvió más rápido. Comprobar tiene que ponerse al día.
El testing de desarrollo web con IA necesita una comprobación independiente contra el producto en ejecución, porque las pruebas escritas junto a la implementación comparten sus supuestos. Cubre flujos, mantenlo proporcionado y ejecútalo en el pull request.