davideandClaude Opus 5
7237e8ff39
I tre contatori (serieAllenamenti, seriePartite, serieConferme) e streak erano zero fisso in useRosa(): la sezione Serie di presenze del profilo mostrava sempre progresso nullo, i badge legati alla costanza erano impossibili da sbloccare e l'obiettivo Continuita di squadra restava a 0/12. serieConsecutiva() e serieConferme() (src/lib/presenze.ts) derivano le serie dagli eventi passati e da risposte_presenze gia in cache, senza query aggiuntive. Migration m9: nuova colonna risposto_il con l'istante della prima risposta, resa immutabile da un trigger, confrontata con eventi_app.creato_il per le conferme entro 24 ore. Serviva perche aggiornato_il registra l'ultima modifica, quindi chi rispondeva subito e cambiava idea dopo risultava lento. Corregge anche la barra di progresso, che misurava valore/prossimo e tornava indietro a ogni traguardo raggiunto (2/3 = 67%, poi 3/6 = 50%). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Test
Suite eseguita con bun, senza framework né dipendenze aggiuntive: ogni file è
uno script che usa node:assert/strict e termina con codice diverso da zero se
un controllo fallisce.
npm run test # unit (veloce, nessuna rete, nessun database)
npm run test:integration # route server vere
npm run test:e2e # percorsi sull'app servita
npm run test:all # tutto
bun test/unit/badges.test.ts # un singolo file
Il runner (test/run.ts) esegue ogni file in un processo separato, così un test
non può inquinare gli altri.
Struttura
| Cartella | Cosa verifica | Serve rete? |
|---|---|---|
unit/ |
Logica di dominio pura: badge, serie, palloni, pagelle, MVP, cacche, scout, obiettivi, notifiche, parsing CSI, dati della rosa. Più le funzioni pure isolabili nei moduli con hook/rete (validazione upload, guardie push, JWT VAPID, cattura errori, avatar) | No |
integration/ |
Le route /api/public/* sul server di sviluppo: risposte, cache, validazione degli input. Più schema e permessi del Profilo Giocatore (schema-profili) contro il database configurato |
Sì |
e2e/ |
Percorsi completi sull'app servita: schermate, dati CSI fino alla pagina, file PWA, 404 | Sì |
helpers/ |
Avvio del server di test e mini-harness condiviso | — |
Convenzioni
- Nessun test scrive sul database. Integration ed e2e fanno solo letture e
verifiche di validazione: si possono lanciare anche contro l'ambiente reale.
L'unica eccezione apparente è
schema-profili, che tenta scritture da utente anonimo proprio per dimostrare che la RLS le respinge, e poi rilegge la riga per verificare che non sia cambiata: su un UPDATE a zero righe PostgREST risponde 2xx, quindi lo stato conta più del codice di risposta. - I test legati alla migration M2 si saltano da soli dove quella migration non è
ancora applicata, indicandolo nel motivo. Per vederli tutti verdi serve un
database che la contenga:
npx supabase startne crea uno in locale. integrationede2eavviano da soli il server di sviluppo. Per usarne uno già attivo:BASE_URL=http://localhost:8080 npm run test:e2e.- Le variabili d'ambiente vengono lette da
.env; i nomi senza prefisso (SUPABASE_URL,SUPABASE_PUBLISHABLE_KEY) sono derivati da quelliVITE_*. I test che richiedonoSUPABASE_SERVICE_ROLE_KEYsi saltano da soli se manca. - Il check del parsing CSI può girare contro il portale reale:
CSI_LIVE=1 bun test/unit/csi-core.test.ts.
Limite noto
L'app renderizza i contenuti dopo l'idratazione: il server invia solo il guscio (titolo, meta, splash). Gli e2e verificano quindi le risposte HTTP, i dati che alimentano le pagine e i file della PWA, ma non l'interfaccia renderizzata. Per quella servirebbe un driver browser (es. Playwright), oggi non installato.