Din app kommer med bevis
Kliv skriver rigtige tests til de apps, den bygger — og kører dem i en rigtig browser, mod en engangskopi af din database, med en kvittering for hver sideeffekt. Det samme loop, der skriver din app, skriver dens tests og driver dem grønne.
Indbygget testing
Ikke genereret kode og krydsede fingre
De fleste AI-buildere genererer en app og afleverer den — om den faktisk virker, er dit problem. Kliv ejer hele den stack, appen kører på: browseren, API’et, sikkerhedsreglerne, databasen, e-mailpipelinen. Det er det, der gør bevis muligt. Tests er ikke noget, du bolter på senere; de er en del af måden, appen bygges på, kørt af det samme loop, der skrev koden.
Anatomien i en kørsel
Den bedste måde at forstå testsystemet på er at følge én kørsel fra første linje til dommen. Her er, hvad der sker — og hvad der aldrig rører dine rigtige data.
Skriv
AI’en skriver unit-tests, mens den bygger — ægte Vitest og Testing Library, branchens standardstack, ikke en proprietær efterligning. Bed om, at et flow dækkes, og den skriver et Scenario: naviger, klik, udfyld, assertér, i semantiske termer — knappen ved dens navn, feltet ved dets label — ikke en skrøbelig CSS-sti, der dør ved næste redesign.
Kør i en rigtig browser
Tests kører i en rigtig browser mod din faktiske app — rigtig rendering, rigtigt login, rigtig sikkerhed på rækkeniveau. Intet vigtigt mockes: hvis en rettighedsændring lader én bruger læse en andens data, fejler en test på samme måde, som din app ville have gjort.
Fork databasen
Før et Scenario rører data, får det en engangsfork af din database — samme skema, samme regler, ingen af dine rækker i fare. Oprettelser, ændringer og sletninger kører rigtigt og lander på forken; dine filer og din commerce-tilstand klones på samme måde. Når kørslen slutter, smides forken væk.
Fang trafikken ud
E-mails, webhooks og tredjepartskald fanges, ikke sendes. En test kan asserte, at velkomstmailen gik ud, til hvem, med hvad — og ingen e-mail forlader nogensinde bygningen. Dine integrationer forbliver stille, mens din logik bliver trænet.
Kvitteringen
Hver kørsel registrerer, hvad appen faktisk gjorde: hvilke rækker den skrev, hvilke e-mails den ville have sendt, hvilke eksterne kald den forsøgte — hver markeret som accepteret, fanget eller afvist, med årsagen vedhæftet, helt ned til sikkerhedsreglen der blokerede en skrivning. Ikke bare rødt eller grønt: hvad der skete, og hvorfor.
Dommen
Resultater kommer tilbage per tjek, per fil — den fejlede assertion, trinnet der knækkede, sammen med kørslens kvittering. Struktureret fejl er pointen: det er det, der lader samme loop, som skrev koden, finde fejlen, rette den og køre igen.
Gaten
Testresultater gate’r publicering. Et fejlet Scenario stopper releasen, før den når dine brugere — så “det virkede, da vi byggede det” bliver til “det virker nu”, verificeret ved hver ændring i stedet for husket fra demoen.
Hvad testsystemet kan
Bygget ind, kørt for dig og læsbart, når du vil kigge.
Den rigtige teststack
Ægte Vitest, Testing Library og jest-dom kørende i browseren — de samme værktøjer professionelle teams bruger, så testene læses som tests, ikke som en leverandørs dialekt.
Scenario-tests
End-to-end-flows skrevet i semantiske termer — find knappen ved dens rolle, feltet ved dets label — og kør den rigtige app, som en bruger ville.
En engangsdatabase
Hvert Scenario kører mod en fork af din rigtige database. Skrivninger accepteres, asserteres og kasseres — dine data er aldrig en del af eksperimentet.
Intet lækker
Testkørsler fanger e-mail, webhooks og connector-kald i stedet for at sende dem — du kan bevise, at de skete, uden at de sker.
Hver kørsel har en kvittering
En hovedbog over hver sideeffekt, en test skabte — accepteret, fanget eller afvist, med årsagen. Sporet, ikke kun trafiklyset.
Historik og gaten
Kørsler spores over tid, og beståede tests gate’r publicering — verifikation er en stående tilstand for din app, ikke en engangsbegivenhed.
Ofte stillede spørgsmål
Hvem skriver testene?
Det gør AI’en, mens den bygger — unit-tests som standard, i standardstacken. Bed om, at et flow dækkes, så skriver den et Scenario til det. Hver test er læsbar kode i din app; du kan inspicere det hele, og du behøver aldrig.
Rører tests mine rigtige data?
Nej. Scenarier kører mod en engangsfork af din database — skrivninger accepteres dér og smides væk med forken, når kørslen slutter. Filer og commerce-tilstand klones på samme måde, så selv en test der sletter alt, sletter intet.
Sender en test rigtige e-mails eller rammer mine integrationer?
Nej — udgående trafik fanges, ikke sendes. Kørslen registrerer, at e-mailen ville være gået ud, til hvem og med hvad, og testen kan asserte på det. Dine kunder og dine forbundne værktøjer ser aldrig en test.
Hvad ser jeg, når en test fejler?
Resultater per tjek — filen, tjekket, assertionen der fejlede — plus kørslens kvittering over sideeffekter med årsagen til, at hver blev tilladt eller afvist. Den struktur er det, der lader AI’en diagnosticere sin egen fejl og rette den i stedet for at gætte ud fra et screenshot.
Tester tests mine sikkerhedsregler?
Ja — Scenarier kører med rigtigt login mod rigtige regler på rækkeniveau, ikke en mocket session. Hvis en ændring lader en bruger se data, der ikke er deres, fejler testen, før en bruger nogensinde kunne.
Kan en fejlet test blokere en release?
Ja. Scenario-domme gate’r publicering — en rød kørsel stopper releasen, indtil den er grøn igen. Gaten er forskellen på at håbe, at den sidste ændring var sikker, og at vide, at den blev tjekket.
Beskriv din app. Få den bevist.
Indbygget betyder bygget sammen: tests kører mod den samme app, dine brugere ser — så en fejlet checkout-test er en fejlet checkout, ikke en mock.
