# TEST STRATEGY

Ultimo aggiornamento: **{{DATA}}**

---

## 1. Il criterio

Ogni criterio di accettazione di ogni spec ha **almeno un test eseguito**. Lo stato di un
requisito in [`TRACEABILITY.md`](TRACEABILITY.md) diventa ✅ quando il test passa, non quando
il codice è scritto. Ogni difetto `DIF-nn` ha un test che lo riproduce.

## 2. Livelli

| Livello | Cosa verifica | Strumento | Dove |
|---|---|---|---|
| Unitario | funzioni pure, regole di business | <!-- DA COMPILARE --> | |
| Integrazione | servizi + database + code, con simulatori dei sistemi esterni | | |
| Contratto | implementazione contro `openapi.yaml` | | |
| End-to-end | casi d'uso dall'interfaccia | | |

## 3. Simulatori dei sistemi esterni

| Sistema | Simulatore | Comportamenti simulati (anche i guasti) |
|---|---|---|
| <!-- DA COMPILARE --> | | |

## 4. Nominare i test

Il nome del test cita il criterio: `test_D3_sufficiente_urgente_ricorrente_lotto_grande_priorita_1`.

## 5. Esecuzione

<!-- DA COMPILARE: comandi, durata attesa, numero di test (aggiornato in DEVELOPMENT_LOG). -->

## 6. Cosa non verifichiamo

<!-- DA COMPILARE, con il perché. -->