Risposta.

L'automazione dei casi negativi è una parte integrante di un sistema di testing completo. Queste sono verifiche in cui si valida la resilienza del sistema a comportamenti errati, dati non corretti, guasti dei servizi e altre situazioni anomale.

Storia della questione:

In passato, l'attenzione principale era rivolta ai casi positivi (happy paths), poiché erano più facili da automatizzare e mantenere. Tuttavia, le esigenze di qualità sono aumentate e sempre più bug si verificano ai confini, con condizioni errate o non ovvie. Il loro testing manuale diventa rapidamente obsoleto, mentre l'automazione consente di monitorare le degradazioni.

Problema:

Definizione e copertura di tutti i possibili casi negativi
Corretta verifica dei messaggi di errore, validità dello stato del sistema dopo il fallimento dell'operazione
Manutenzione dei test in caso di cambiamenti nella logica di business

Soluzione:

Identificazione e sistematizzazione dei casi negativi (Boundary Value Analysis, Equivalence Partitioning)
Utilizzo di assert personalizzati e validatori per verificare i testi degli errori, i codici HTTP, le eccezioni
"Ripristino" automatico dello stato del sistema dopo un test negativo

Caratteristiche chiave:

Esplicita formulazione dei test per errori, eccezioni, dati di input non standard
Verifica del messaggio di errore e dello stato interno del sistema
Controllo degli effetti collaterali: dopo un test negativo, il sistema deve rimanere in uno stato consistente

Domande trabocchetto.

È sufficiente verificare solo quali errori vengono restituiti durante il testing negativo?

No. È importante verificare non solo il contenuto dell'errore, ma anche che dopo l'errore non ci siano stati cambiamenti nello stato del sistema (ad esempio, non sia stata aggiunta una registrazione non corretta nel database).

È necessario automatizzare tutti i possibili casi negativi?

No. Ce ne possono essere un numero infinito; è necessario identificare i più probabili e critici (Boundary Value, Null/Empty, tipo errato, attacchi SQL, ecc.) e gli altri man mano che si presentano bug.

Si può utilizzare la stessa elaborazione per tutti i casi negativi?

No. Diversi casi negativi richiedono controlli, gestione delle eccezioni e rollback diversi; gli assert generici non sono sufficienti.

Errori comuni e antipattern

Ignorare i casi negativi o coprirli "per finta"
Controllo delle informazioni di errore poco convincente (ad esempio, solo codice 500, ma non verifica del testo o degli effetti collaterali)
Ambiente di test non ripulito dopo il fallimento del test

Esempio dalla vita reale

Caso Negativo

Nel sistema vengono testati solo scenari di registrazione validi. La registrazione con email vuoto non viene controllata automaticamente. Di conseguenza, il problema che consente la registrazione di un utente con un'email vuota viene notato solo in produzione.

Vantaggi:

Semplice manutenzione dei test
Basso numero di test automatici e rapido completamento

Svantaggi:

Bug critici emergono in produzione
Aumentano i costi di correzione e rollback

Caso Positivo

Per ciascun caso negativo (assenza di email, formato non corretto, attacco SQL) esiste un test automatizzato che verifica esplicitamente l'assenza di un nuovo account e il contenuto del messaggio di errore.