Tu aplicación viene con prueba
Kliv escribe pruebas reales para las aplicaciones que crea y las ejecuta en un navegador real, contra una copia desechable de tu base de datos, con un recibo por cada efecto secundario. El mismo bucle que escribe tu aplicación escribe tus pruebas y las pone en verde.
Pruebas integradas
Código no generado y dedos cruzados.
La mayoría de los creadores de AI generan una aplicación y la entregan; si realmente funciona es tu problema. Kliv posee toda la pila en la que se ejecuta la aplicación: el navegador, API, las reglas de seguridad, la base de datos, el canal de correo electrónico. Eso es lo que hace posible la prueba. Las pruebas no son algo que se haga más tarde; son parte de cómo se construye la aplicación y se ejecutan mediante el mismo bucle que escribió el código.
La anatomía de una ejecución
La mejor manera de entender el sistema de pruebas es seguir una ejecución desde la primera línea hasta el veredicto. Esto es lo que sucede y lo que nunca toca tus datos reales.
Escribir
La AI escribe pruebas unitarias a medida que las construye: Vitest y Testing Library reales, la pila estándar de la industria, no una imitación patentada. Pide que se cubra un flujo y escribe un Scenario: navegar, hacer clic, completar, afirmar, en términos semánticos (el botón por tu nombre, el campo por tu etiqueta), no una ruta CSS frágil que muere en el próximo rediseño.
Ejecutar en un navegador real
Las pruebas se ejecutan en un navegador real en tu aplicación real: representación real, inicio de sesión real, seguridad real a nivel de fila. No se burla de nada que importa: si un cambio de permisos permite a un usuario leer los datos de otro, una prueba falla de la misma manera que lo habría hecho tu aplicación.
Bifurcar la base de datos
Antes de que un Scenario toque los datos, obtiene una bifurcación desechable de tu base de datos: el mismo esquema, las mismas reglas, ninguna de tus filas en riesgo. Las creaciones, ediciones y eliminaciones se ejecutan de verdad y aterrizan en la bifurcación; tus archivos y el estado comercial se clonan de la misma manera. Cuando termina la ejecución, se tira el fork.
Capturar la salida
Los correos electrónicos, webhooks y llamadas de terceros se capturan, no se activan. Una prueba puedes afirmar que se envió el correo electrónico de bienvenida, a quién, con qué, y que ningún correo electrónico sale del edificio. Tus integraciones permanecen silenciosas mientras se ejercita tu lógica.
el recibo
Cada ejecución registra lo que realmente hizo la aplicación: qué filas escribió, qué correos electrónicos habría enviado, qué llamadas externas intentó; cada una marcada como aceptada, capturada o rechazada, con el motivo adjunto, hasta la regla de seguridad que bloqueó una escritura. No sólo rojo o verde: qué pasó y por qué.
el veredicto
Los resultados se obtienen por verificación, por archivo: la afirmación fallida, el paso que falló, junto con el recibo de la ejecución. El punto es el fallo estructurado: es lo que permite que el mismo bucle que escribió el código encuentre el error, lo solucione y lo ejecuta de nuevo.
la puerta
Publicación de los resultados de las pruebas. Un Scenario defectuoso detiene el lanzamiento antes de que llegue a tus usuarios, por lo que “funcionó cuando lo creamos” se convierte en “funciona ahora”, verificado en cada cambio en lugar de recordado en la demostración.
Lo que el sistema de prueba sabe hacer
Integrado, ejecutado por ti y legible cuando quieras verlo.
La verdadera pila de pruebas
Vitest genuino, biblioteca de pruebas y jest-dom ejecutándose en el navegador: las mismas herramientas que usan los equipos profesionales, por lo que las pruebas se leen como pruebas, no como el dialecto de un proveedor.
Scenario pruebas
Flujos de un extremo a otro escritos en términos semánticos (busque el botón por tu función, el campo por tu etiqueta), impulsando la aplicación real como lo haría un usuario.
Una base de datos desechable
Cada Scenario se ejecuta en una bifurcación de tu base de datos real. Las escrituras se aceptan, se afirman y se descartan; tus datos nunca forman parte del experimento.
Nada gotea
Las ejecuciones de prueba capturan correos electrónicos, webhooks y llamadas de conector en lugar de enviarlos; puedes demostrar que sucedieron sin que sucedieran.
Cada ejecución tiene un recibo.
Un registro de todos los efectos secundarios que provocó una prueba: aceptados, capturados o rechazados, con el motivo. La traza, no sólo el semáforo.
Historia y la puerta
Las ejecuciones se rastrean a lo largo del tiempo y la aprobación de las pruebas permite la publicación: la verificación es un estado permanente de tu aplicación, no un evento único.
Preguntas comunes
¿Quién escribe las pruebas?
La AI lo hace, a medida que construye: pruebas unitarias de forma predeterminada, en la pila estándar. Pide que se cubra un flujo y te escribe un Scenario. Cada prueba es un código legible en tu aplicación; puedes inspeccionar cualquiera de ellos y nunca tendrás que hacerlo.
¿Las pruebas tocan mis datos reales?
No. Scenarios se ejecuta en una bifurcación desechable de tu base de datos; las escrituras se aceptan allí y se desechan con la bifurcación cuando finaliza la ejecución. Los archivos y el estado del comercio se clonan de la misma manera, por lo que incluso una prueba que elimina todo no elimina nada.
¿Una prueba enviará correos electrónicos reales o afectará a mis integraciones?
No: el tráfico saliente se captura, no se envía. La ejecución registra que se habría enviado el correo electrónico, a quién y con qué, y la prueba puedes afirmarlo. Tus clientes y tus herramientas conectadas nunca ven una prueba.
¿Qué veo cuando falla una prueba?
Resultados por verificación (el archivo, la verificación, la afirmación que falló) más la recepción de los efectos secundarios de la ejecución con el motivo por el cual se permitió o rechazó cada uno. Esa estructura es lo que permite al la AI diagnostique tu propio error y corregirlo, en lugar de adivinar a partir de una captura de pantalla.
¿Las pruebas ejercen mis reglas de seguridad?
Sí, Scenarios se ejecuta con un inicio de sesión real según reglas reales a nivel de fila, no con una sesión simulada. Si un cambio permite a un usuario ver datos que no son suyos, la prueba falla antes de que el usuario puedas hacerlo.
¿Puedes una prueba fallida bloquear una versión?
Sí. Scenario veredicto de publicación de puerta: una ejecución en rojo detiene la publicación hasta que vuelve a estar en verde. La puerta es la diferencia entre esperar que el último cambio haya sido seguro y saber que fue verificado.
Describe tu aplicación. Haz que se demuestre.
Integrado significa construido en conjunto: las pruebas se ejecutan en la misma aplicación que ven tus usuarios, por lo que una prueba de pago fallida es un pago fallido, no una simulación.
