For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/web/testing.md (or send Accept: text/markdown).
Strategia di test
Comprendi cosa stabiliscono i controlli deterministici, browser, database e provider.
Installazione e configurazione
Prima di qualsiasi passaggio, leggere Prima di iniziare e Nozioni di base sui terminali. Queste istruzioni presuppongono che tu abbia aperto l'intero supastack monorepo in VS Code; la sua radice package.json contrassegna la radice del repository. Nei comandi pnpm, un pacchetto dell'area di lavoro è un'app o una cartella di codice condiviso; nel prodotto, uno spazio di lavoro è il contenitore dei dati di un team e il limite di sicurezza. corepack pnpm --filter ... seleziona un pacchetto dal monorepo mentre i comandi vengono eseguiti dalla sua radice. Se hai aperto solo una cartella mobile o desktop sincronizzata, non contiene il backend Web, la configurazione di Docker o gli script root: esegui il backend da questo monorepo o da un server ospitato raggiungibile e utilizza gli script della cartella della piattaforma. Una variabile di ambiente è un'impostazione denominata memorizzata in un file .env locale o nel dashboard dell'hosting; riavvia l'app pertinente dopo averla modificata e mantieni i segreti del server fuori dai valori NEXT_PUBLIC_ e EXPO_PUBLIC_.
1. Apri il repository-root package.json per vedere i comandi check.
2. Da quella cartella principale eseguire corepack pnpm test per unit test automatizzati, quindi corepack pnpm --filter @supastack/web typecheck per controlli Web TypeScript.
3. Per verificare il comportamento del browser, avviare l'app Web ed eseguire corepack pnpm test:e2e. Previsto: ogni comando riporta il proprio risultato; un test unitario non dimostra che un vero database, fornitore di servizi di pagamento, servizio di posta elettronica o telefono funzioni.
La suite di test predefinita usa adattatori fake/locali deterministici. I test browser coprono le interazioni utente; l'accettazione del database e lo smoke dei provider esterni sono cancelli separati. Esegui i controlli rilevanti al comportamento cambiato prima di allargare l'ambito.
corepack pnpm test
corepack pnpm check
corepack pnpm build
corepack pnpm test:e2e
corepack pnpm test:e2e:productionComandi da copiare
Segui i commenti per vedere in quale cartella viene eseguito un comando. Se due terminali sono etichettati, apri due finestre di terminale e mantieni il primo comando in esecuzione mentre usi il secondo.
corepack pnpm test
corepack pnpm --filter @supastack/web typecheck
corepack pnpm test:e2eFlusso di implementazione
Per i cambiamenti di comportamento, scrivi prima un test di accettazione che fallisce. Abbina l'accesso riuscito a richieste anonime e tra workspace rifiutate. Per form e flussi di attività, verifica caricamento, errore e ripristino oltre al percorso felice.
Una risposta browser intercettata dimostra che l'interfaccia risponde a quel fixture. Non dimostra persistenza dell'auth, elaborazione dei pagamenti, consegna dei provider o un callback su dispositivo fisico.
Verifica e risoluzione dei problemi
Se un test del database indica che è stato saltato, impostare il relativo database di test isolato prima di segnalare la copertura del database. Se una scheda Web si trova sulla porta 3001, è il server apps/docs separato; l'app Web del kit inizia alla porta 3000. Se Playwright fallisce alla prima esecuzione di Windows, lascia terminare l'installazione del browser ed esegui nuovamente il comando in errore; non disattivare mai la sicurezza a livello di sistema per aggirare il problema.
Se un test condizionato dal database salta, configura il suo database di test isolato prima di affermare che quel cancello è passato. Se un runner browser emette assertion che passano ma si blocca al teardown, riporta entrambi i fatti; un processo bloccato non è un comando riuscito pulito.
Su Windows, l'esecuzione iniziale del browser potrebbe scadere mentre Defender esegue la scansione dei browser o delle dipendenze di Playwright appena installati. Lascia che l'installazione finisca, esegui nuovamente la suite non riuscita con corepack pnpm test:e2e o corepack pnpm test:e2e:production e controlla la traccia e la cronologia di Defender Protection se fallisce nuovamente. Lascia abilitata la protezione a livello di sistema.
La suite del browser locale possiede la porta 3100 e rifiuta di riutilizzare un processo già in ascolto lì. Imposta PLAYWRIGHT_PORT su una porta libera prima del corepack pnpm test:e2e se un'altra app possiede 3100; questo impedisce ai test di prendere di mira silenziosamente un altro progetto.