31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
 
|
# DD-020 — Una funzione modificata senza test non è finita
|
||
|
|
|
||
|
|
**Data:** 4 settembre 2026
|
||
|
|
**Stato:** Accettata
|
||
|
|
|
||
|
|
**Contesto**
|
||
|
|
Con `main` come branch di lavoro (DD-019) non c'è più un ambiente di prova tra il codice e i
|
||
|
|
giocatori. La suite in `test/` esisteva già ma scriverla era di fatto facoltativo, e i difetti
|
||
|
|
trovati dai test sono arrivati a posteriori (la sessione Scout Live che non scadeva mai, le
|
||
|
|
serie di presenze ferme a zero per settimane).
|
||
|
|
|
||
|
|
**Decisione**
|
||
|
|
Chi aggiunge o modifica una funzione scrive o aggiorna il test nello stesso lavoro, e i test
|
||
|
|
devono essere verdi prima di consegnare. Non si commenta un test che fallisce né si indebolisce
|
||
|
|
un'asserzione per farla passare: se il comportamento voluto è cambiato, si aggiorna il test
|
||
|
|
dicendo perché.
|
||
|
|
|
||
|
|
**Alternative scartate**
|
||
|
|
|
||
|
|
- Test solo sui moduli critici → il confine «critico» si sposta a ogni fretta.
|
||
|
|
- Introdurre un framework di test → la suite bun con `node:assert` funziona e non aggiunge
|
||
|
|
dipendenze (vedi [test/README.md](../../test/README.md)).
|
||
|
|
|
||
|
|
**Conseguenze**
|
||
|
|
|
||
|
|
- La logica di dominio va tenuta separabile dagli hook (`*-core.ts`), altrimenti non è
|
||
|
|
testabile in `test/unit/` senza rete.
|
||
|
|
- Le modifiche costano un po' di più; le regressioni in produzione costano di più.
|
||
|
|
|
||
|
|
**Riesame**
|
||
|
|
Se comparisse un ambiente di staging stabile che rende superflua parte della copertura.
|