La tua app viene fornita con una prova
Kliv scrive test reali per le app che crea e li esegue in un browser reale, rispetto a una copia usa e getta del tuo database, con una ricevuta per ogni effetto collaterale. Lo stesso ciclo che scrive la tua app scrive i suoi test e li rende verdi.
Test integrato
Codice non generato e dita incrociate
La maggior parte dei builder AI genera un’app e la consegna: se funziona davvero è un tuo problema. Kliv possiede l’intero stack su cui viene eseguita l’app: il browser, API, le regole di sicurezza, il database, la pipeline di posta elettronica. Questo è ciò che rende possibile la prova. I test non sono qualcosa a cui ti imbarchi in seguito; fanno parte del modo in cui viene creata l’app, gestiti dallo stesso ciclo che ha scritto il codice.
L’anatomia di un’esecuzione
Il modo migliore per comprendere il sistema di test è seguire una sequenza dalla prima riga al verdetto. Ecco cosa succede e cosa non tocca mai i tuoi dati reali.
Scrivi
L’AI scrive test unitari mentre costruisce: libreria Vitest e Testing Library autentica, stack standard del settore, non un’imitazione proprietaria. Chiedi che un flusso venga coperto e scrive un Scenario: navigare, fare clic, riempire, affermare, in termini semantici — il pulsante con il suo nome, il campo con la sua etichetta — non un fragile percorso CSS che muore nella prossima riprogettazione.
Esegui in un browser reale
I test vengono eseguiti in un browser reale rispetto alla tua app reale: rendering reale, accesso reale, sicurezza reale a livello di riga. Non viene deriso nulla di ciò che conta: se una modifica delle autorizzazioni consente a un utente di leggere i dati di un altro, un test fallisce come avrebbe fatto la tua app.
Effettua il fork del database
Prima che un Scenario tocchi i dati, ottiene un fork usa e getta del tuo database: stesso schema, stesse regole, nessuna delle tue righe a rischio. Crea, modifica ed elimina l’esecuzione reale e finiscono sul fork; i tuoi file e lo stato commerciale vengono clonati allo stesso modo. Quando l’esecuzione finisce, il fork viene gettata via.
Cattura l’uscita
Le email, i webhook e le chiamate di terze parti vengono catturati, non attivati. Un test può affermare che l’e-mail di benvenuto è stata inviata, a chi, con cosa e che nessuna e-mail lascia mai l’edificio. Le tue integrazioni restano silenziose mentre la tua logica viene esercitata.
La ricevuta
Ogni esecuzione registra ciò che l’app ha effettivamente fatto: quali righe ha scritto, quali email avrebbe inviato, quali chiamate esterne ha tentato: ognuna contrassegnata come accettata, catturata o rifiutata, con il motivo allegato, fino alla regola di sicurezza che ha bloccato una scrittura. Non solo rosso o verde: cosa è successo e perché.
Il verdetto
I risultati vengono restituiti per controllo, per file: l’asserzione fallita, il passaggio che si è rotto, insieme alla ricevuta dell’esecuzione. Il punto è il fallimento strutturato: è ciò che consente allo stesso ciclo che ha scritto il codice di trovare l’errore, correggerlo ed eseguire di nuovo.
Il cancello
Pubblicazione dei risultati dei test. Un Scenario non riuscito interrompe il rilascio prima che raggiunga i tuoi utenti, quindi “ha funzionato quando l’abbiamo creato” diventa “funziona ora”, verificato a ogni modifica anziché ricordato dalla demo.
Cosa sa fare il sistema di test
Integrato, eseguito per te e leggibile quando vuoi guardare.
Il vero stack di test
Vitest autentico, libreria di test e jest-dom in esecuzione nel browser: gli stessi strumenti utilizzati dai team di professionisti, quindi i test si leggono come test, non come il dialetto di un fornitore.
Scenario test
Flussi end-to-end scritti in termini semantici (trova il pulsante in base al suo ruolo, il campo in base alla sua etichetta) guidando l’app reale come farebbe un utente.
Un database usa e getta
Ogni Scenario viene eseguito contro un fork del tuo database reale. Le scritture vengono accettate, confermate e scartate: i tuoi dati non fanno mai parte dell’esperimento.
Non trapela nulla
Le esecuzioni di test acquisiscono e-mail, webhook e chiamate ai connettori invece di inviarli: puoi dimostrare che sono avvenuti senza che si verificassero.
Ogni esecuzione ha una ricevuta
Un registro di tutti gli effetti collaterali causati da un test: accettato, catturato o rifiutato, con il motivo. La traccia, non solo il semaforo.
La storia e la porta
Le esecuzioni vengono monitorate nel tempo e il superamento dei test determina la pubblicazione: la verifica è uno stato permanente della tua app, non un evento una tantum.
Domande comuni
Chi scrive i test?
L’AI scrive, durante la creazione, test unitari per impostazione predefinita, nello stack standard. Richiedi che un flusso venga coperto e per esso scrive un Scenario. Ogni test è codice leggibile nella tua app; puoi ispezionare qualsiasi cosa e non dovrai mai farlo.
I test toccano i miei dati reali?
No. Scenario viene eseguito contro un fork usa e getta del tuo database: le scritture vengono accettate lì e scartate con il fork al termine dell’esecuzione. I file e lo stato commerciale vengono clonati allo stesso modo, quindi anche un test che elimina tutto non elimina nulla.
Un test invierà email reali o colpirà le mie integrazioni?
No: il traffico in uscita viene acquisito, non inviato. L’esecuzione registra che l’email sarebbe stata inviata, a chi e con cosa, e il test può affermarlo. I tuoi clienti e i tuoi strumenti connessi non vedono mai un test.
Cosa vedo quando un test fallisce?
Risultati per controllo (il file, il controllo, l’asserzione che non è riuscita) più la ricezione degli effetti collaterali dell’esecuzione con il motivo per cui ciascuno è stato autorizzato o rifiutato. Questa struttura è ciò che consente all’AI di diagnosticare il proprio errore e risolverlo, invece di indovinare da uno screenshot.
I test esercitano le mie regole di sicurezza?
Sì: i Scenario vengono eseguiti con un accesso reale rispetto a regole reali a livello di riga, non con una sessione fittizia. Se una modifica consente a un utente di vedere dati che non gli appartengono, il test fallisce prima che l’utente possa farlo.
Un test fallito può bloccare un rilascio?
Sì. I verdetti degli Scenario bloccano la pubblicazione: un’esecuzione rossa interrompe il rilascio finché non diventa di nuovo verde. Il cancello è la differenza tra sperare che l’ultima modifica sia stata sicura e sapere che è stata controllata.
Descrivi la tua app. Fallo provare.
Integrato significa costruito insieme: i test vengono eseguiti sulla stessa app visualizzata dagli utenti, quindi un test di pagamento fallito è un checkout fallito, non una simulazione.
