Votre app est accompagnée d’une preuve
Kliv écrit de vrais tests pour les apps qu’il crée et les exécute dans un vrai navigateur, sur une copie jetable de votre base de données, avec un reçu pour chaque effet secondaire. La même boucle qui écrit votre app écrit ses tests et les rend verts.
Tests intégrés
Code non généré et croisons les doigts
La plupart des builders AI génèrent une app et la transmettent — votre problème est de savoir si elle fonctionne réellement. Kliv possède toute la stack sur laquelle l’app s’exécute : le navigateur, l’API, les règles de sécurité, la base de données, le pipeline de messagerie. C’est ce qui rend la preuve possible. Les tests ne sont pas quelque chose que vous faites plus tard ; ils font partie de la façon dont l’app est construite, exécutée par la même boucle qui a écrit le code.
L’anatomie d’une course
La meilleure façon de comprendre le système de test est de suivre une séquence depuis la première ligne jusqu’au verdict. Voici ce qui se passe et ce qui n’affecte jamais vos données réelles.
Écrire
Le AI écrit des tests unitaires au fur et à mesure de sa construction : une véritable bibliothèque de tests et de tests Vitest, la stack standard de l’industrie, et non une imitation propriétaire. Demandez qu’un flux soit couvert et il écrit un Scenario : naviguez, cliquez, remplissez, affirmez, en termes sémantiques — le bouton par son nom, le champ par son étiquette — pas un chemin CSS fragile qui meurt lors de la prochaine refonte.
Exécuter dans un vrai navigateur
Les tests s’exécutent dans un vrai navigateur sur votre app réelle : rendu réel, connexion réelle, sécurité réelle au niveau des lignes. Rien d’important n’est moqué : si une modification des autorisations permet à un utilisateur de lire les données d’un autre, un test échoue comme le ferait votre app.
Forkez la base de données
Avant qu’un Scenario ne touche les données, il obtient un fork jetable de votre base de données : même schéma, mêmes règles, aucune de vos lignes n’est menacée. Crée, modifie et supprime l’exécution réelle et atterrit sur le fork ; vos fichiers et votre état commercial sont clonés de la même manière. Une fois la course terminée, la fourchette est jetée.
Capturer la sortie
Les e-mails, les webhooks et les appels tiers sont capturés et non déclenchés. Un test peut affirmer que l’e-mail de bienvenue a été envoyé, à qui, avec quoi, et qu’aucun e-mail ne quitte jamais le bâtiment. Vos intégrations restent silencieuses pendant que votre logique s’exerce.
Le reçu
Chaque exécution enregistre ce que l’app a réellement fait : quelles lignes elle a écrites, quels e-mails elle aurait envoyés, quels appels externes elle a tentés — chacun étant marqué comme accepté, capturé ou refusé, avec la raison attachée, jusqu’à la règle de sécurité qui a bloqué une écriture. Pas seulement rouge ou vert : que s’est-il passé et pourquoi.
Le verdict
Les résultats reviennent par vérification, par fichier : l’assertion défaillante, l’étape qui a échoué, ainsi que le reçu de l’exécution. L’échec structuré est le point important : c’est ce qui permet à la même boucle qui a écrit le code de trouver l’erreur, de la corriger et de l’exécuter à nouveau.
La porte
Publication des résultats des tests. Un Scenario défaillant arrête la version avant qu’elle n’atteigne vos utilisateurs — ainsi « cela fonctionnait lorsque nous l’avons construit » devient « cela fonctionne maintenant », vérifié à chaque modification au lieu d’être mémorisé dans la démo.
Ce que le système de test sait faire
Intégré, exécuté pour vous et lisible lorsque vous souhaitez consulter.
La véritable stack de tests
Véritable Vitest, Testing Library et jest-dom exécutés dans le navigateur : les mêmes outils que les équipes professionnelles utilisent, de sorte que les tests se lisent comme des tests, pas comme le dialecte d’un fournisseur.
Tests Scenario
Des flux de bout en bout écrits en termes sémantiques — recherchez le bouton par son rôle, le champ par son étiquette — pilotant la véritable app comme le ferait un utilisateur.
Une base de données jetable
Chaque Scenario s’exécute sur un fork de votre base de données réelle. Les écritures sont acceptées, affirmées et rejetées : vos données ne font jamais partie de l’expérience.
Rien ne fuit
Les exécutions de tests capturent les e-mails, les webhooks et les appels de connecteur au lieu de les envoyer : vous pouvez prouver qu’ils se sont produits sans qu’ils ne se produisent.
Chaque course a un reçu
Un registre de tous les effets secondaires provoqués par un test — acceptés, capturés ou refusés, avec la raison. La trace, pas seulement le feu tricolore.
L’histoire et la porte
Les exécutions sont suivies au fil du temps et la réussite des tests précède la publication : la vérification est un état permanent de votre app, et non un événement ponctuel.
Questions courantes
Qui rédige les tests ?
Le AI effectue, au fur et à mesure de sa construction, des tests unitaires par défaut, dans la stack standard. Demandez qu’un flux soit couvert et il écrit un Scenario pour cela. Chaque test est un code lisible dans votre app ; vous pouvez inspecter n’importe lequel d’entre eux, et vous n’aurez jamais à le faire.
Les tests touchent-ils mes données réelles ?
Non. Les Scenario s’exécutent sur un fork jetable de votre base de données — les écritures y sont acceptées et supprimées avec le fork à la fin de l’exécution. Les fichiers et l’état commercial sont clonés de la même manière, donc même un test qui supprime tout ne supprime rien.
Un test enverra-t-il de vrais e-mails ou affectera-t-il mes intégrations ?
Non : le trafic sortant est capturé et non envoyé. L’exécution enregistre que l’e-mail aurait été envoyé, à qui et avec quoi, et le test peut le confirmer. Vos clients et vos outils connectés ne voient jamais de test.
Que puis-je voir lorsqu’un test échoue ?
Résultats par vérification (le fichier, la vérification, l’assertion qui a échoué) ainsi que la réception des effets secondaires de l’exécution avec la raison pour laquelle chacun a été autorisé ou refusé. Cette structure permet au AI de diagnostiquer sa propre erreur et de la corriger, au lieu de deviner à partir d’une capture d’écran.
Les tests appliquent-ils mes règles de sécurité ?
Oui : les Scenario s’exécutent avec une connexion réelle par rapport à de véritables règles au niveau des lignes, et non avec une session simulée. Si une modification permet à un utilisateur de voir des données qui ne lui appartiennent pas, le test échoue avant qu’un utilisateur ne le puisse.
Un test échoué peut-il bloquer une version ?
Oui. Publication des verdicts Scenario : une exécution rouge arrête la publication jusqu’à ce qu’elle redevienne verte. La porte fait la différence entre espérer que le dernier changement a été sécuritaire et savoir qu’il a été vérifié.
Décrivez votre app. Faites-le prouver.
Intégré signifie construit ensemble : les tests sont exécutés sur la même app que vos utilisateurs voient — donc un test de paiement qui échoue est un échec de checkout, pas une simulation.
