> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Strategia di test

Comprendi cosa stabiliscono i controlli deterministici, browser, database e provider.

## Installazione e configurazione

Prima di qualsiasi passaggio, leggere [Prima di iniziare](https://supastack.dev/it/docs/web/before-you-start.md) e [Nozioni di base sui terminali](https://supastack.dev/it/docs/web/terminal-basics.md). 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:production
```


## Comandi 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:e2e
```


## Flusso 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.


## Successivo

[Checklist di deployment](https://supastack.dev/it/docs/web/deployment.md)