Prompt per generare test con Claude Code per i casi-limite

Perché generare solo test happy-path fa perdere tempo

I suite di test generate automaticamente spesso sembrano impressionanti: decine di test, molto codice di setup e ogni nome di funzione appare da qualche parte. Ma molti di quei test sono solo controlli del tipo “funziona quando tutto è normale”. Passano facilmente, raramente trovano bug e comunque costano tempo per essere letti e mantenuti.

Con un tipico prompt per la generazione di test con Claude Code, il modello tende a rispecchiare gli input d'esempio che vede. Ottieni variazioni che sembrano diverse ma coprono lo stesso comportamento. Il risultato è una grande suite con copertura sottile dove conta davvero.

I test ad alto segnale sono diversi. Sono il piccolo insieme che avrebbe intercettato l'incidente del mese scorso. Falliscono quando il comportamento cambia in modo rischioso e restano stabili quando avvengono refactor innocui. Un test ad alto segnale può valere venti controlli “restituisce il valore atteso”.

La generazione di basso valore per gli happy-path di solito ha alcuni sintomi chiari:

• Molti test differiscono solo nelle etichette di input, non in ciò che può rompersi.
• Le asserzioni sono superficiali (“non nullo”, “status è 200”) invece di controllare il significato.
• Il setup è più pesante del comportamento testato, così le persone smettono di aggiornare i test.
• La copertura sembra alta, ma i casi limite sono intoccati.

Immagina una funzione che applica un codice sconto. I test happy-path confermano che “SAVE10” riduce il prezzo. I veri bug si nascondono altrove: prezzi 0 o negativi, codici scaduti, problemi di arrotondamento o limiti massimi di sconto. Sono quei casi che generano totali sbagliati, clienti arrabbiati e rollback a mezzanotte.

L'obiettivo è spostarsi da “più test” a “test migliori” mirando a tre bersagli: confini, modalità di errore e invarianti.

I tre obiettivi: confini, modalità di errore, invarianti

Se vuoi unit test ad alto segnale, smetti di chiedere “più test” e inizia a chiedere tre tipi specifici. Questo è il nucleo di un prompt per la generazione di test con Claude Code che produce copertura utile invece di una pila di controlli “funziona su input normale”.

1) Confini (dove si nascondono i bug)

I confini sono i margini di ciò che il codice accetta o produce. Molti difetti reali sono off-by-one, stati vuoti o problemi di timeout che non compaiono in un happy path.

Pensa in termini di minimi e massimi (0, 1, lunghezza massima), vuoto vs presente ("", [], nil), off-by-one (n-1, n, n+1) e limiti temporali (vicino alla soglia).

Esempio: se un'API accetta “fino a 100 elementi”, testa 100 e 101, non solo 3.

2) Modalità di errore (dimostra che fallisce in modo sicuro)

Le failure mode sono i modi in cui il sistema può rompersi: input errati, dipendenze mancanti, risultati parziali o errori a monte. Buoni test per le modalità di errore controllano il comportamento sotto stress, non solo l'output in condizioni ideali.

Esempio: quando una chiamata al database fallisce, la funzione restituisce un errore chiaro ed evita di scrivere dati parziali?

3) Invarianti (regole che devono sempre valere)

Le invarianti sono verità che dovrebbero restare vere prima e dopo una chiamata. Trasformano la correttezza vaga in asserzioni nette.

Esempi:

• “Balance non diventa mai negativo” dopo qualsiasi tentativo di prelievo.
• “Gli ID sono unici” anche se crei elementi rapidamente.
• “In caso di errore, nessun cambiamento di stato” (nessuna nuova riga, nessuna flag attivata).

Quando ti concentri su questi tre obiettivi, ottieni meno test ma ognuno ha più segnale.

Preparazione: estrai un piccolo contratto prima di scrivere i test

Se chiedi test troppo presto, di solito ottieni una pila di controlli “funziona come previsto”. Una semplice soluzione è scrivere prima un piccolo contratto, poi generare test da quel contratto. È il modo più veloce per trasformare un prompt di generazione di test con Claude Code in qualcosa che trova bug reali.

Un contratto utile è abbastanza breve da poter essere letto in un respiro. Mira a 5–10 righe che rispondano a tre domande: cosa entra, cosa esce e cos'altro cambia.

Un template di contratto di 5–10 righe

Scrivi il contratto in linguaggio semplice, non in codice, e includi solo ciò che puoi testare.

• Inputs: tipi, range consentiti e cosa conta come “vuoto” o “mancante”.
• Output: valore di ritorno o forma dell'errore e cosa garantisce il “successo”.
• Effetti collaterali: cambiamenti di stato, righe DB, chiamate di rete, file, log.
• Assunzioni: cose che i chiamanti sbagliano spesso (fuso orario, encoding, auth, ordinamento).
• “Non deve mai succedere”: crash, perdita silente di dati, doppio addebito, scritture parziali.

Una volta che hai questo, scansiona per capire dove la realtà può infrangere le assunzioni. Quelli diventano casi limite (min/max, zero, overflow, stringhe vuote, duplicati) e modalità di errore (timeout, permesso negato, violazioni di vincoli unici, input corrotti).

Ecco un esempio concreto per una feature come reserveInventory(itemId, qty):

Il contratto potrebbe dire che qty deve essere un intero positivo, la funzione deve essere atomica e non deve mai creare stock negativo. Questo suggerisce subito test ad alto segnale: qty = 0, qty = 1, qty maggiore della disponibilità, chiamate concorrenti e un errore forzato al DB a metà operazione.

Se usi uno strumento di tipo vibe-coding come Koder.ai, lo stesso workflow si applica: scrivi prima il contratto in chat, poi genera test che attacchino direttamente confini, modalità di errore e la lista “non deve mai succedere”.

Pattern del prompt: blueprint per test ad alto segnale

Usa questo prompt per la generazione di test con Claude Code quando vuoi meno test ma ciascuno più efficace. La mossa chiave è imporre prima un piano di test, poi generare codice solo dopo che il piano è stato approvato.

You are helping me write HIGH-SIGNAL unit tests.

Context
- Language/framework: <fill in>
- Function/module under test: <name + short description>
- Inputs: <types, ranges, constraints>
- Outputs: <types + meaning>
- Side effects/external calls: <db, network, clock, randomness>

Contract (keep it small)
1) Preconditions: <what must be true>
2) Postconditions: <what must be true after>
3) Error behavior: <how failures are surfaced>

Task
PHASE 1 (plan only, no code):
A) Propose 6-10 tests max. Do not include “happy path” unless it protects an invariant.
B) For each test, state: intent, setup, input, expected result, and WHY it is high-signal.
C) Invariants: list 3-5 invariants and how each will be asserted.
D) Boundary matrix: propose a small matrix of boundary values (min/max/empty/null/off-by-one/too-long/invalid enum).
E) Failure modes: list negative tests that prove safe behavior (no crash, no partial write, clear error).
Stop after PHASE 1 and ask for approval.

PHASE 2 (after approval):
Generate the actual test code with clear names and minimal mocks.

Un trucco pratico è richiedere la matrice dei confini come tabella compatta, così i gap risultano evidenti:

Se Claude propone 20 test, spingi indietro. Chiedi di unire casi simili e di tenere solo quelli che effettivamente catturerebbero un bug reale (off-by-one, tipo di errore sbagliato, perdita silente di dati, invariante rotta).

Passo-passo: esegui il prompt e trasforma l'output in test

Inizia con un contratto piccolo e concreto per il comportamento che vuoi. Incolla la signature della funzione, una breve descrizione di input e output e eventuali test esistenti (anche se sono solo happy-path). Questo mantiene il modello ancorato a ciò che il codice fa realmente, non a ciò che suppone.

Poi chiedi una tabella dei rischi prima di chiedere qualsiasi codice di test. Richiedi tre colonne: casi limite (bordi dell'input valido), modalità di errore (input cattivi, dati mancanti, timeout) e invarianti (regole che devono sempre valere). Aggiungi una frase per riga: “perché questo può rompersi”. Una tabella semplice rivela gap più velocemente di una pila di file di test.

Quindi scegli il set più piccolo di test in cui ognuno ha uno scopo unico di cattura bug. Se due test falliscono per lo stesso motivo, tieni quello più forte.

Una regola pratica di selezione:

• Tieni test che colpiscono confini diversi (min, max, vuoto, off-by-one).
• Tieni test che provano comportamento sicuro sotto failure (errore chiaro, nessuna scrittura parziale, nessun crash).
• Tieni test che asseriscono un'invariante (ordinamento, totali, idempotenza, nessun duplicato).
• Elimina test che ripetono solo “funziona con input normale”.

Infine, richiedi una breve spiegazione per test: quale bug catturerebbe se fallisse. Se la spiegazione è vaga (“valida il comportamento”), probabilmente il test è a basso segnale.

Come codificare le invarianti nelle asserzioni

Un'invariante è una regola che dovrebbe restare vera qualunque input valido tu passi. Con il testing basato su invarianti, prima scrivi la regola in linguaggio semplice, poi la trasformi in un'asserzione che possa fallire in modo rumoroso.

Scegli 1 o 2 invarianti che ti proteggono davvero dai bug. Buone invarianti riguardano spesso la sicurezza (nessuna perdita di dati), la consistenza (stessi input, stessi output) o limiti (non superare mai certi capi).

Trasformare un'invariante in un controllo appurabile

Scrivi l'invariante come una breve frase, poi decidi quale evidenza il test può osservare: valori di ritorno, dati memorizzati, eventi emessi o chiamate alle dipendenze. Le asserzioni forti controllano sia l'esito sia gli effetti collaterali, perché molti bug si nascondono in “ha restituito OK ma ha scritto la cosa sbagliata”.

Per esempio, supponi di avere una funzione che applica un coupon a un ordine:

• Invariante: il totale finale non è mai negativo.
• Invariante: applicare lo stesso coupon due volte non sconta due volte.

Ora codifica queste come asserzioni che misurano qualcosa di concreto:

expect(result.total).toBeGreaterThanOrEqual(0)
expect(db.getOrder(orderId).discountCents).toBe(originalDiscountCents)

Evita asserzioni vaghe come “restituisce il risultato atteso”. Asserisci la regola specifica (non negativo) e l'effetto collaterale specifico (sconto memorizzato una sola volta).

Aggiungi una nota di controesempio così il test resta tagliente

Per ogni invariante, aggiungi una breve nota nel test su quali dati la violerebbero. Questo impedisce che il test si trasformi nel tempo in un controllo happy-path.

Un semplice schema che regge nel tempo:

• Metti l'invariante nel nome del test.
• Asserisci l'invariante sull'output.
• Asserisci l'effetto collaterale chiave (o la sua assenza).
• Aggiungi un commento che descriva un caso di violazione (per esempio, un coupon enorme o un'applicazione duplicata).

Failure modes: scrivi test che dimostrino comportamento sicuro

I test ad alto segnale spesso sono quelli che confermano che il codice fallisce in modo sicuro. Se un modello genera solo test happy-path, impari quasi nulla su come la feature si comporta quando input e dipendenze diventano difficili.

Inizia decidendo cosa significa “sicuro” per quella feature. Restituisce un errore tipato? Fa fallback a un default? Ritenta una volta e poi si ferma? Scrivi il comportamento atteso in una frase, poi fai sì che i test lo dimostrino.

Quando chiedi a Claude Code test per le failure mode, mantieni l'obiettivo stretto: copri i modi in cui il sistema può rompersi e asserisci la risposta esatta che vuoi. Una linea utile è: “Preferisci meno test con asserzioni più forti piuttosto che molti test superficiali.”

Categorie di failure che danno spesso i migliori test:

• Input cattivi: formati non validi, campi richiesti mancanti, valori fuori range
• Fallimenti di dipendenze: timeout, 500, risposte vuote, payload corrotti
• Problemi di ordinamento: eventi fuori ordine, duplicati, scritture parziali
• Concorrenza: aggiornamenti in race, controlli di idempotenza
• Comportamento di recovery: quando ritorni errore vs fai fallback vs ritenti

Esempio: hai un endpoint che crea un utente e chiama un servizio email per inviare un messaggio di benvenuto. Un test a basso valore verifica “restituisce 201.” Un test di failure ad alto segnale verifica che se il servizio email va in timeout, tu o (a) crei comunque l'utente e ritorni 201 con un flag “email_pending”, oppure (b) ritorni un 503 chiaro e non crei l'utente. Scegli un comportamento, poi asserisci sia la risposta sia gli effetti collaterali.

Testa anche cosa non fai trapelare. Se la validazione fallisce, assicurati che nulla venga scritto nel database. Se una dipendenza ritorna un payload corrotto, assicurati di non lanciare eccezioni non gestite o restituire stack trace raw.

Trappole comuni che creano test di scarso valore

I set di test a basso valore nascono spesso quando il modello è premiato per il volume. Se il tuo prompt chiede “20 unit test”, spesso ottieni piccole variazioni che sembrano esaustive ma non intercettano novità.

Trappole comuni:

• Test simili: lo stesso test “input valido” ripetuto con stringhe o numeri diversi.
• Test che riflettono l'implementazione: asserire passaggi privati o chiamate helper invece del comportamento osservabile.
• Mockare tutto: sostituire DB, clock, network e config contemporaneamente.
• Asserzioni deboli: controllare solo “nessun errore”, “non nullo” o “status 200”.
• Stato condiviso sporco: lasciare dati seeded, globali modificati o cache residue.

Esempio: immagina una funzione “create user”. Dieci test happy-path potrebbero variare la stringa email e comunque perdere il punto importante: respingere email duplicate, gestire password vuote e garantire che gli ID utente restituiti siano unici e stabili.

Guardrail utili in revisione:

• Richiedi a ogni test di nominare il rischio che copre (confine, modalità di errore o invariante).
• Evita controlli solo sull'implementazione a meno che non cambino il comportamento osservabile.
• Mantieni i mock al minimo e permetti qualche test che tocchi il punto di integrazione reale quando fattibile.
• Pretendi asserzioni forti: output esatti, cambi di stato e tipi/messaggi di errore.
• Aggiungi regole di cleanup così i test non dipendono dall'ordine.

Esempio: trasformare una feature in un piccolo set di test forti

Immagina una feature: applicare un codice coupon al checkout.

Contratto (piccolo e testabile): dato un subtotale del carrello in centesimi e un coupon opzionale, restituisci un totale finale in centesimi. Regole: i coupon percentuali arrotondano per difetto al centesimo più vicino, i coupon fissi sottraggono una somma fissa e i totali non vanno mai sotto 0. Un coupon può essere invalido, scaduto o già usato.

Non chiedere “test per applyCoupon()”. Chiedi test per casi limite, modalità di errore e invarianti legate a questo contratto.

Confini per forzare comportamenti al limite

Scegli input che tendono a rompere la matematica o la validazione: stringa coupon vuota, subtotal = 0, subtotal appena sotto e sopra una spesa minima, uno sconto fisso maggiore del subtotale e una percentuale come 33% che crea problemi di arrotondamento.

Modalità di errore per dimostrare comportamento sicuro

Assumi che la lookup del coupon possa fallire e che lo stato possa essere errato: il servizio coupon è giù, il coupon è scaduto o il coupon è già stato riscattato dall'utente. Il test dovrebbe dimostrare cosa succede dopo (coupon rifiutato con errore chiaro, totale invariato).

Un set minimo e ad alto segnale di test (5 test) e cosa cattura ciascuno:

• Rifiuto di codice vuoto o solo spazi: cattura bug tipo “accetta vuoto come valido” e problemi di trim.
• Arrotondamento percentuale (subtotal 101, 33%): cattura errori di arrotondamento e off-by-one di centesimi.
• Sconto fisso maggiore del subtotale (subtotal 500, discount 1000): dimostra l'invariante che il totale non diventa negativo.
• Soglia di spesa minima (subtotal 999 vs 1000): cattura logica di confronto sbagliata (< vs <=).
• Fallimento lookup coupon o timeout: dimostra fallback sicuro (nessuno sconto applicato) e gestione stabile degli errori.

Se questi passano, hai coperto i punti di rottura comuni senza riempire la suite con test happy-path duplicati.

Lista di controllo rapida per test AI-generated ad alto segnale

Prima di accettare ciò che il modello genera, fai un rapido controllo qualità. L'obiettivo è test che proteggano ognuno da un bug specifico e probabile.

Usa questa checklist come gate:

• Confini per ogni input: per ogni campo (stringhe, ID, timestamp, flag), includi almeno un caso limite (vuoto vs solo spazi, lunghezza massima, zero vs negativo, campi opzionali mancanti, uno oltre il limite).
• Fallimenti di dipendenze: includi almeno un test in cui una dipendenza si comporta male (timeout DB, API terze parti 500, token auth scaduto). Dimostra comportamento sicuro (errore chiaro, nessuna scrittura parziale).
• Invarianti con asserzioni forti: scegli 1–3 regole che devono sempre valere e asseriscile direttamente. Evita asserzioni vaghe come “response ok”.
• Un bug unico per test: leggi il titolo di ogni test e chiediti “Quale bug esatto catturerebbe questo?”. Se due test rispondono alla stessa domanda, uniscili.
• Test di rimozione: prova a cancellare un test. Se non perdi nulla di significativo (nessun confine, nessuna modalità di errore, nessuna invariante), non meritava di restare.

Un trucco pratico dopo la generazione: rinomina i test in “should <comportamento> when <condizione limite>” e “should not <esito negativo> when <failure>”. Se non riesci a rinominarli chiaramente, non sono focalizzati.

Se costruisci con Koder.ai, questa checklist si integra bene con snapshot e rollback: genera test, eseguili e fai rollback se il nuovo set aggiunge rumore senza migliorare la copertura.

Prossimi passi: rendilo un workflow ripetibile

Tratta il tuo prompt come un'arnese riutilizzabile, non come una richiesta una tantum. Salva un blueprint del prompt (quello che forza confini, modalità di errore e invarianti) e riusalo per ogni nuova funzione, endpoint o flow UI.

Un'abitudine semplice che migliora i risultati: chiedi una frase per test che spieghi quale bug catturerebbe. Se quella frase è generica, il test è probabilmente rumore.

Tieni una lista viva di invarianti di dominio per il tuo prodotto. Non tenerla solo in testa. Aggiungila ogni volta che trovi un bug reale.

Un workflow leggero che puoi ripetere:

• Estrai un piccolo contratto: inputs, outputs, gestione errori e 3–5 invarianti.
• Esegui il blueprint prompt e richiedi confini, modalità di errore, invarianti e giustificazioni in una riga.
• Implementa solo i migliori 5–10 test che coprono rischi distinti.
• Refattorizza, poi riesegui il prompt per vedere quali nuovi rischi emergono.
• Potare i duplicati e mantenere i test che avrebbero intercettato incidenti passati.

Se costruisci app via chat, esegui questo ciclo dentro Koder.ai (koder.ai) così contratto, piano e test generati vivono nello stesso posto. Quando un refactor cambia comportamento inaspettatamente, snapshot e rollback rendono più semplice confrontare e iterare finché il set ad alto segnale resta stabile.