Generare test con l'AI è una delle applicazioni più utili dell'AI-assisted coding. Il modello può leggere una funzione, proporre casi limite, creare fixture e scrivere test ripetitivi. Ma un test generato non è automaticamente un buon test.
Il rischio principale è la copertura apparente: tanti test verdi che non proteggono il comportamento.
Aggiornamento luglio 2026
Gli agenti AI moderni possono generare test, eseguirli, leggere il fallimento e correggere sia test sia codice. Questo accelera molto, ma rende ancora più importante distinguere tra test utili e test che confermano l'implementazione corrente. L'obiettivo non è aumentare coverage: è rendere costosi i regressi.
La best practice 2026 è chiedere prima una matrice di casi, poi far generare i test. Per unit test, concentrati su contratto pubblico, edge case e bug reali. Per E2E, usa ruoli accessibili, label e selettori stabili; evita assertion su classi CSS o DOM interno. Questo si collega direttamente a una buona base di accessibilità WCAG. Per flussi critici, fai fallire volontariamente il codice o usa mutation testing per capire se le assertion mordono davvero.
Integra i test in CI e conserva il prompt o la decisione di test nei casi delicati: permessi, pagamenti, prezzi, sicurezza, migrazioni database e privacy.
Unit test: buon punto di partenza
Per funzioni pure, validatori, parser e utility, l'AI può generare rapidamente casi di test. È utile chiedere esplicitamente:
- happy path;
- input vuoti;
- valori null o undefined;
- limiti numerici;
- formati non validi;
- errori attesi;
- compatibilità con casi già presenti.
Un prompt efficace:
Scrivi test unitari per questa funzione.
Copri happy path, input invalidi e casi limite.
Non testare l implementazione interna: testa solo il comportamento pubblico.L'ultima frase è importante. Un buon test deve sopravvivere a un refactor.
Test E2E
Con Playwright o Cypress, l'AI può aiutare a scrivere journey: login, ricerca, checkout, invio form, navigazione. È utile quando il flusso è chiaro e ci sono selettori stabili.
Il problema è che spesso genera test fragili basati su testo o struttura DOM instabile. Meglio usare ruoli accessibili, label e data-testid solo dove necessario.
Un test E2E deve verificare un risultato utente, non un dettaglio interno. "Il messaggio di conferma è visibile" è meglio di "la classe CSS è cambiata".
Il rischio dei test tautologici
Il test tautologico è quello che conferma il mock invece del comportamento reale. Esempio: si mocka una funzione per restituire true e poi si verifica che il risultato sia true. Il test è verde, ma non dimostra nulla.
L'AI può cadere spesso in questo schema, soprattutto quando non ha contesto sul sistema. Per evitarlo:
- limita i mock;
- testa output osservabili;
- verifica side effect reali;
- usa fixture realistiche;
- controlla che il test fallisca se rompi il codice.
Mutation testing
Il mutation testing è un buon controllo della qualità dei test. Modifica automaticamente il codice in piccoli punti e verifica se i test falliscono. Se non falliscono, forse le assertion sono deboli.
Non serve applicarlo ovunque. È utile su logiche critiche: prezzi, permessi, validazioni, calcoli, sicurezza.
Workflow consigliato
Un flusso efficace, da affiancare a una code review AI, è:
- chiedi all'AI una lista di casi da coprire;
- scegli quelli rilevanti;
- genera una prima bozza;
- riscrivi assertion e fixture;
- esegui i test;
- rompi intenzionalmente il codice per verificare che falliscano;
- integra in CI.
L'AI accelera le parti meccaniche. Il giudizio su cosa conta resta umano.
Metriche: copertura reale vs apparente
La coverage percentuale è utile, ma non basta. Un file può avere alta copertura e test deboli. Meglio combinare:
- coverage;
- mutation score su parti critiche;
- review dei casi limite;
- test E2E sui flussi principali;
- bug reali trasformati in regressioni testate.
Conclusione
I test generati con AI sono una grande opportunità se vengono trattati come bozza. Possono ridurre il tempo di scrittura e far emergere casi non considerati. Ma la qualità nasce dalle assertion, dai dati realistici e dalla verifica che il test fallisca quando il comportamento si rompe.