Din app kommer med bevis
Kliv skriver riktiga tester för apparna den bygger – och kör dem i en riktig webbläsare, mot en kastbar kopia av din databas, med ett kvitto för varje sidoeffekt. Samma loop som skriver appen skriver dess tester och driver dem gröna.
Inbyggd testning
Inte genererad kod och hållna tummar
De flesta AI-byggare genererar en app och lämnar över den – om den faktiskt fungerar blir ditt problem. Kliv äger hela stacken appen kör på: webbläsaren, API:t, säkerhetsreglerna, databasen, e-postflödet. Det är det som gör bevis möjliga. Tester är inte något du skruvar på senare; de är en del av hur appen byggs, körda av samma loop som skrev koden.
En körnings anatomi
Bästa sättet att förstå testsystemet är att följa en körning från första raden till omdömet. Här är vad som händer – och vad som aldrig rör dina riktiga data.
Skriv
AI:n skriver enhetstester medan den bygger – riktig Vitest och Testing Library, branschstandardstacken, inte en egen imitation. Be om att ett flöde ska täckas så skriver den ett Scenario: navigera, klicka, fyll i, kontrollera, i semantiska termer – knappen efter namn, fältet efter etikett – inte en spröd CSS-väg som dör vid nästa redesign.
Kör i en riktig webbläsare
Tester kör i en riktig webbläsare mot din faktiska app – riktig rendering, riktig inloggning, riktig radnivåsäkerhet. Inget som spelar roll mockas: om en behörighetsändring låter en användare läsa en annans data misslyckas ett test på samma sätt som appen skulle ha gjort.
Forka databasen
Innan ett Scenario rör data får det en kastbar fork av din databas – samma schema, samma regler, inga av dina rader i riskzonen. Skapanden, ändringar och raderingar kör på riktigt och landar i forken; dina filer och commerce-tillstånd klonas på samma sätt. När körningen slutar kastas forken.
Fånga utgående trafik
Mejl, webhooks och tredjepartsanrop fångas, skickas inte. Ett test kan kontrollera att välkomstmejlet gick ut, till vem, med vad – och inget mejl lämnar någonsin byggnaden. Dina integrationer är tysta medan logiken övas.
Kvittot
Varje körning registrerar vad appen faktiskt gjorde: vilka rader den skrev, vilka mejl den skulle ha skickat, vilka externa anrop den försökte göra – varje markeras som accepterad, fångad eller vägrad, med skälet bifogat, ända ner till säkerhetsregeln som blockerade en skrivning. Inte bara rött eller grönt: vad som hände, och varför.
Omdömet
Resultat kommer tillbaka per kontroll, per fil – assertionen som misslyckades, steget som brast, bredvid körningens kvitto. Strukturerat misslyckande är poängen: det är vad som låter samma loop som skrev koden hitta felet, fixa det och köra igen.
Grinden
Testresultat grindar publicering. Ett misslyckat Scenario stoppar releasen innan den når dina användare – så ”det fungerade när vi byggde det” blir ”det fungerar nu”, verifierat vid varje ändring i stället för ihågkommet från demon.
Vad testsystemet kan göra
Inbyggt, kört åt dig och läsbart när du vill titta.
Den riktiga teststacken
Riktig Vitest, Testing Library och jest-dom som kör i webbläsaren – samma verktyg professionella team använder, så testerna läses som tester, inte som en leverantörsdialekt.
Scenario-tester
End-to-end-flöden skrivna i semantiska termer – hitta knappen efter roll, fältet efter etikett – och kör den riktiga appen som en användare skulle göra.
En kastbar databas
Varje Scenario kör mot en fork av din riktiga databas. Skrivningar accepteras, kontrolleras och kastas – dina data är aldrig en del av experimentet.
Inget läcker
Testkörningar fångar mejl, webhooks och connector-anrop i stället för att skicka dem – du kan bevisa att de hände utan att de händer.
Varje körning har ett kvitto
En huvudbok över varje sidoeffekt ett test orsakade – accepterad, fångad eller vägrad, med skälet. Spåret, inte bara trafikljuset.
Historik och grinden
Körningar följs över tid, och passerade tester grindar publicering – verifiering är ett stående tillstånd för appen, inte en engångshändelse.
Vanliga frågor
Vem skriver testerna?
AI:n gör det, medan den bygger – enhetstester som standard, i standardstacken. Be om att ett flöde ska täckas så skriver den ett Scenario för det. Varje test är läsbar kod i appen; du kan granska allt, och du behöver aldrig göra det.
Rör tester mina riktiga data?
Nej. Scenarier kör mot en kastbar fork av din databas – skrivningar accepteras där och kastas med forken när körningen slutar. Filer och commerce-tillstånd klonas på samma sätt, så även ett test som raderar allt raderar ingenting.
Skickar ett test riktiga mejl eller träffar mina integrationer?
Nej – utgående trafik fångas, skickas inte. Körningen registrerar att mejlet skulle ha gått ut, till vem och med vad, och testet kan kontrollera det. Dina kunder och anslutna verktyg ser aldrig ett test.
Vad ser jag när ett test misslyckas?
Resultat per kontroll – filen, kontrollen, assertionen som misslyckades – plus körningens kvitto över sidoeffekter med skälet till att varje tilläts eller vägrades. Den strukturen är vad som låter AI:n diagnostisera sitt eget fel och fixa det, i stället för att gissa från en skärmbild.
Övar tester mina säkerhetsregler?
Ja – Scenarier kör med riktig inloggning mot riktiga radnivåregler, inte en mockad session. Om en ändring låter en användare se data som inte är deras misslyckas testet innan en användare någonsin kan göra det.
Kan ett misslyckat test blockera en release?
Ja. Scenario-omdömen grindar publicering – en röd körning stoppar releasen tills den är grön igen. Grinden är skillnaden mellan att hoppas att senaste ändringen var säker och att veta att den kontrollerades.
Beskriv din app. Få den bevisad.
Inbyggt betyder byggt tillsammans: tester kör mot samma app som dina användare ser – så ett misslyckat kassatest är en misslyckad kassa, inte en mock.
