Ihre App kommt mit Beweis
Kliv schreibt echte Tests für die Apps, die es baut – und führt sie in einem echten Browser aus, gegen eine wegwerfbare Kopie Ihrer Datenbank, mit Beleg für jeden Seiteneffekt. Dieselbe Schleife, die Ihre App schreibt, schreibt ihre Tests und bringt sie auf grün.
Eingebaute Tests
Kein generierter Code und gedrückte Daumen
Die meisten AI-Builder generieren eine App und übergeben sie – ob sie tatsächlich funktioniert, ist Ihr Problem. Kliv besitzt den ganzen Stack, auf dem die App läuft: Browser, API, Sicherheitsregeln, Datenbank, E-Mail-Pipeline. Genau das macht Beweis möglich. Tests werden nicht später angeschraubt; sie sind Teil davon, wie die App gebaut wird, ausgeführt von derselben Schleife, die den Code geschrieben hat.
Die Anatomie eines Laufs
Das Testsystem versteht man am besten, wenn man einem Lauf von der ersten Zeile bis zum Urteil folgt. Hier ist, was passiert – und was Ihre echten Daten nie berührt.
Schreiben
Die AI schreibt Unit-Tests, während sie baut – echtes Vitest und Testing Library, der branchenübliche Stack, keine proprietäre Nachahmung. Bitten Sie darum, einen Flow abzudecken, und sie schreibt ein Scenario: navigieren, klicken, ausfüllen, prüfen, in semantischen Begriffen – den Button nach seinem Namen, das Feld nach seinem Label – nicht einen fragilen CSS-Pfad, der beim nächsten Redesign stirbt.
In einem echten Browser laufen
Tests laufen in einem echten Browser gegen Ihre tatsächliche App – echtes Rendering, echte Anmeldung, echte Sicherheit auf Zeilenebene. Nichts, was zählt, wird gemockt: Wenn eine Berechtigungsänderung einen Nutzer die Daten eines anderen lesen lässt, schlägt ein Test so fehl, wie Ihre App es getan hätte.
Die Datenbank forken
Bevor ein Scenario Daten berührt, erhält es einen wegwerfbaren Fork Ihrer Datenbank – dasselbe Schema, dieselben Regeln, keine Ihrer Zeilen in Gefahr. Erstellen, Bearbeiten und Löschen laufen echt und landen im Fork; Ihre Dateien und Ihr Commerce-Status werden genauso geklont. Wenn der Lauf endet, wird der Fork weggeworfen.
Egress erfassen
E-Mails, Webhooks und Drittanbieteraufrufe werden erfasst, nicht ausgelöst. Ein Test kann prüfen, dass die Willkommensmail rausgegangen wäre, an wen und mit welchem Inhalt – und keine E-Mail verlässt jemals das Gebäude. Ihre Integrationen bleiben still, während Ihre Logik ausgeübt wird.
Der Beleg
Jeder Lauf zeichnet auf, was die App tatsächlich getan hat: welche Zeilen sie geschrieben hat, welche E-Mails sie gesendet hätte, welche externen Aufrufe sie versucht hat – jeder als akzeptiert, erfasst oder verweigert markiert, mit Grund, bis zur Sicherheitsregel, die einen Schreibzugriff blockiert hat. Nicht nur rot oder grün: was passiert ist und warum.
Das Urteil
Ergebnisse kommen pro Check, pro Datei zurück – die fehlgeschlagene Assertion, der Schritt, der brach, neben dem Beleg des Laufs. Strukturierter Fehler ist der Punkt: Er lässt dieselbe Schleife, die den Code geschrieben hat, den Fehler finden, beheben und erneut laufen.
Die Schranke
Testergebnisse sperren die Veröffentlichung. Ein fehlgeschlagenes Scenario stoppt das Release, bevor es Ihre Nutzer erreicht – aus „es funktionierte, als wir es gebaut haben“ wird „es funktioniert jetzt“, bei jeder Änderung geprüft statt aus der Demo erinnert.
Was das Testsystem kann
Eingebaut, für Sie ausgeführt und lesbar, wenn Sie hineinschauen möchten.
Der echte Test-Stack
Echtes Vitest, Testing Library und jest-dom im Browser – dieselben Tools, die professionelle Teams nutzen, damit Tests wie Tests lesen, nicht wie ein Anbieterdialekt.
Scenario-Tests
End-to-End-Flows in semantischen Begriffen geschrieben – den Button nach seiner Rolle finden, das Feld nach seinem Label – und die echte App so steuern, wie ein Nutzer es tun würde.
Eine wegwerfbare Datenbank
Jedes Scenario läuft gegen einen Fork Ihrer echten Datenbank. Schreibvorgänge werden akzeptiert, geprüft und verworfen – Ihre Daten sind nie Teil des Experiments.
Nichts leckt
Testläufe erfassen E-Mail, Webhooks und Connector-Aufrufe, statt sie zu senden – Sie können beweisen, dass sie passiert wären, ohne dass sie passieren.
Jeder Lauf hat einen Beleg
Ein Ledger jedes Seiteneffekts, den ein Test verursacht hat – akzeptiert, erfasst oder verweigert, mit Grund. Die Spur, nicht nur die Ampel.
Historie und Schranke
Läufe werden über Zeit verfolgt, und bestandene Tests sperren oder öffnen die Veröffentlichung – Verifikation ist ein stehender Zustand Ihrer App, kein einmaliges Ereignis.
Häufige Fragen
Wer schreibt die Tests?
Die AI erledigt das, während sie baut – Unit-Tests standardmäßig im Standard-Stack. Bitten Sie darum, einen Flow abzudecken, und sie schreibt ein Scenario dafür. Jeder Test ist lesbarer Code in Ihrer App; Sie können alles prüfen und müssen es nie.
Berühren Tests meine echten Daten?
Nein. Scenarios laufen gegen einen wegwerfbaren Fork Ihrer Datenbank – Schreibvorgänge werden dort akzeptiert und mit dem Fork weggeworfen, wenn der Lauf endet. Dateien und Commerce-Status werden genauso geklont, sodass selbst ein Test, der alles löscht, nichts löscht.
Sendet ein Test echte E-Mails oder trifft meine Integrationen?
Nein – ausgehender Verkehr wird erfasst, nicht gesendet. Der Lauf zeichnet auf, dass die E-Mail rausgegangen wäre, an wen und mit welchem Inhalt, und der Test kann darauf prüfen. Ihre Kunden und verbundenen Tools sehen nie einen Test.
Was sehe ich, wenn ein Test fehlschlägt?
Ergebnisse pro Check – Datei, Check, fehlgeschlagene Assertion – plus den Beleg des Laufs über Seiteneffekte mit dem Grund, warum jeder erlaubt oder verweigert wurde. Diese Struktur lässt die AI ihren eigenen Fehler diagnostizieren und beheben, statt anhand eines Screenshots zu raten.
Üben Tests meine Sicherheitsregeln aus?
Ja – Scenarios laufen mit echter Anmeldung gegen echte Zeilenregeln, nicht mit gemockter Sitzung. Wenn eine Änderung einen Nutzer Daten sehen lässt, die nicht seine sind, schlägt der Test fehl, bevor ein Nutzer es könnte.
Kann ein fehlgeschlagener Test ein Release blockieren?
Ja. Scenario-Urteile sperren die Veröffentlichung – ein roter Lauf stoppt das Release, bis er wieder grün ist. Die Schranke ist der Unterschied zwischen hoffen, dass die letzte Änderung sicher war, und wissen, dass sie geprüft wurde.
Beschreiben Sie Ihre App. Erhalten Sie den Beweis.
Eingebaut heißt zusammen gebaut: Tests laufen gegen dieselbe App, die Ihre Nutzer sehen – ein fehlgeschlagener Checkout-Test ist also ein fehlgeschlagener Checkout, kein Mock.
