Je app komt met bewijs
Kliv schrijft echte tests voor de apps die het bouwt — en draait ze in een echte browser, tegen een wegwerpbare kopie van je database, met een bon voor elk neveneffect. Dezelfde loop die je app schrijft, schrijft de tests en stuurt ze naar groen.
Ingebouwde testing
Geen gegenereerde code en duimen draaien
De meeste AI-builders genereren een app en dragen die over — of hij echt werkt is jouw probleem. Kliv beheert de hele stack waarop de app draait: de browser, de API, de beveiligingsregels, de database, de e-mailpijplijn. Daardoor wordt bewijs mogelijk. Tests zijn niet iets wat je later toevoegt; ze zijn onderdeel van hoe de app wordt gebouwd, gedraaid door dezelfde loop die de code schreef.
De anatomie van een run
De beste manier om het testsysteem te begrijpen is één run te volgen van de eerste regel tot het oordeel. Dit gebeurt er — en dit raakt je echte data nooit.
Schrijven
De AI schrijft unit tests terwijl hij bouwt — echte Vitest en Testing Library, de industriestandaard stack, geen eigen imitatie. Vraag om een flow te dekken en hij schrijft een Scenario: navigeren, klikken, invullen, assert, in semantische termen — de knop op naam, het veld op label — geen broos CSS-pad dat bij het volgende redesign breekt.
Draaien in een echte browser
Tests draaien in een echte browser tegen je daadwerkelijke app — echte rendering, echt inloggen, echte beveiliging op rijniveau. Niets wordt gemockt dat ertoe doet: als een permissiewijziging één gebruiker data van een ander laat lezen, faalt een test zoals je app zou falen.
De database forken
Voordat een Scenario data raakt, krijgt het een wegwerpbare fork van je database — hetzelfde schema, dezelfde regels, geen van je rijen in gevaar. Aanmaken, bewerken en verwijderen draaien echt en landen op de fork; je bestanden en commerce-state worden op dezelfde manier gekloond. Wanneer de run eindigt, wordt de fork weggegooid.
De egress vastleggen
E-mails, webhooks en calls naar derden worden vastgelegd, niet verstuurd. Een test kan assert dat de welkomstmail eruit zou gaan, naar wie, met wat — en er verlaat nooit een e-mail het gebouw. Je integraties blijven stil terwijl je logica echt wordt geoefend.
De bon
Elke run legt vast wat de app echt deed: welke rijen hij schreef, welke e-mails hij zou hebben verzonden, welke externe calls hij probeerde — elk gemarkeerd als geaccepteerd, vastgelegd of geweigerd, met de reden erbij, tot aan de beveiligingsregel die een write blokkeerde. Niet alleen rood of groen: wat gebeurde er, en waarom.
Het oordeel
Resultaten komen terug per check, per bestand — de falende assert, de stap die brak, naast de bon van neveneffecten van de run. Gestructureerd falen is het punt: daardoor kan dezelfde loop die de code schreef de fout vinden, oplossen en opnieuw draaien.
De poort
Testresultaten blokkeren publiceren. Een falende Scenario stopt de release voordat die je gebruikers bereikt — zodat “het werkte toen we het bouwden” verandert in “het werkt nu”, geverifieerd bij elke wijziging in plaats van onthouden uit de demo.
Wat het testsysteem kan
Ingebouwd, voor je gedraaid en leesbaar wanneer je wilt kijken.
De echte teststack
Echte Vitest, Testing Library en jest-dom die in de browser draaien — dezelfde tools die professionele teams gebruiken, zodat de tests lezen als tests, niet als het dialect van een leverancier.
Scenario-tests
End-to-end flows geschreven in semantische termen — vind de knop op rol, het veld op label — die de echte app besturen zoals een gebruiker dat zou doen.
Een wegwerpbare database
Elke Scenario draait tegen een fork van je echte database. Writes worden geaccepteerd, geassert en weggegooid — je data is nooit onderdeel van het experiment.
Niets lekt
Testruns leggen e-mail, webhooks en connectorcalls vast in plaats van ze te versturen — je kunt bewijzen dat ze gebeurden zonder dat ze gebeuren.
Elke run heeft een bon
Een grootboek van elk neveneffect dat een test veroorzaakte — geaccepteerd, vastgelegd of geweigerd, met de reden. Het spoor, niet alleen het stoplicht.
Geschiedenis en de poort
Runs worden door de tijd gevolgd, en geslaagde tests blokkeren of openen publiceren — verificatie is een blijvende staat van je app, geen eenmalig event.
Veelgestelde vragen
Wie schrijft de tests?
De AI doet dat terwijl hij bouwt — standaard unit tests, in de standaard stack. Vraag om een flow te dekken en hij schrijft er een Scenario voor. Elke test is leesbare code in je app; je kunt alles inspecteren, maar dat hoeft nooit.
Raken tests mijn echte data?
Nee. Scenarios draaien tegen een wegwerpbare fork van je database — writes worden daar geaccepteerd en met de fork weggegooid wanneer de run eindigt. Bestanden en commerce-state worden op dezelfde manier gekloond, dus zelfs een test die alles verwijdert verwijdert niets.
Stuurt een test echte e-mails of raakt hij mijn integraties?
Nee — uitgaand verkeer wordt vastgelegd, niet verstuurd. De run legt vast dat de e-mail eruit zou zijn gegaan, naar wie en met wat, en de test kan daarop assert. Je klanten en gekoppelde tools zien nooit een test.
Wat zie ik wanneer een test faalt?
Resultaten per check — het bestand, de check, de assert die faalde — plus de bon van neveneffecten van de run met de reden waarom elk werd toegestaan of geweigerd. Die structuur laat de AI zijn eigen fout diagnosticeren en oplossen, in plaats van te gokken op basis van een screenshot.
Oefenen tests mijn beveiligingsregels?
Ja — Scenarios draaien met echt inloggen tegen echte regels op rijniveau, niet tegen een gemockte sessie. Als een wijziging een gebruiker data laat zien die niet van die persoon is, faalt de test voordat een gebruiker dat ooit kan.
Kan een falende test een release blokkeren?
Ja. Scenario-oordelen blokkeren publiceren — een rode run stopt de release totdat hij weer groen is. De poort is het verschil tussen hopen dat de laatste wijziging veilig was en weten dat die gecontroleerd is.
Beschrijf je app. Krijg hem bewezen.
Ingebouwd betekent samen gebouwd: tests draaien tegen dezelfde app die je gebruikers zien — dus een falende checkouttest is een falende checkout, geen mock.
