Indice

Se lo sviluppo è un atto di costruzione, la scrittura di test è un atto di decostruzione controllata. L'obiettivo non è provare che il software funziona, ma cercare attivamente tutti i modi in cui potrebbe fallire.

Un buon set di test è la rete di sicurezza che permette a un team di muoversi velocemente, di fare refactoring con fiducia e di aggiungere nuove funzionalità senza paura di rompere quelle esistenti.

Il Problema della Mentalità del Test

Scrivere test è un'attività dispendiosa e richiede una mentalità diversa, quasi opposta, a quella dello sviluppo:

  • Lo sviluppatore pensa al "happy path", il percorso felice dove tutto va come previsto
  • Il tester deve pensare a tutto il resto: input malformati, errori di rete, condizioni di concorrenza, casi limite improbabili ma possibili

Questa differenza di mindset rende difficile per molti sviluppatori scrivere test davvero efficaci. Tendiamo a testare ciò che sappiamo già funziona, non ciò che potrebbe rompersi.

La Copertura Non È Qualità

Il classico errore è confondere "code coverage" con "test quality":

  • 90% di copertura del codice
  • 200 test che passano tutti
  • Ma il software crasha in produzione al primo input inaspettato

Perché? Perché i test verificano solo gli scenari "ovvi", non i casi limite subdoli che causano i veri problemi.

L'Avvocato del Diavolo Entra in Scena

Qui, l'IA assume il ruolo dell'Avvocato del Diavolo, un partner che sfida costantemente le nostre assunzioni.

Livello 1: Generazione Test di Routine

Possiamo usare un'IA efficiente come Qwen-Coder per il lavoro di routine:

"Data questa classe UserService, genera gli unit test per ogni metodo pubblico, coprendo i casi di input validi e nulli."

Risultato: 20-30 test generati in secondi invece di ore, coprendo:

  • Happy path per ogni metodo
  • Gestione parametri null
  • Gestione array/liste vuote
  • Validazione eccezioni attese

Livello 2: Strategia e Casi Limite

Il vero valore aggiunto si ottiene quando usiamo un'IA più creativa come Claude per la strategia:

"Analizza la logica di questa funzione che calcola uno sconto. Quali sono i casi limite più subdoli che potrei non aver considerato?"

Risposta dell'IA potrebbe includere:

  • Sconti che si sommano superando il 100%
  • Date di validità che cadono in un anno bisestile
  • Valute con un numero diverso di decimali (Yen vs Euro)
  • Overflow in calcoli con numeri molto grandi
  • Arrotondamenti che causano differenze di centesimi in batch da 10.000 ordini
  • Timezone diversi che cambiano la "data corrente"
  • Comportamento durante cambio ora legale/solare

Esempio Pratico: Funzione Calcolo Sconto

Codice originale:

function calculateDiscount(orderAmount, customerLevel, promoCode) {
  let discount = 0;
  
  if (customerLevel === "gold") discount += 10;
  if (customerLevel === "platinum") discount += 20;
  if (promoCode === "SUMMER2024") discount += 15;
  
  return orderAmount * (discount / 100);
}

Test "ovvio" che uno sviluppatore scriverebbe:

test("calculates gold customer discount", () => {
  expect(calculateDiscount(100, "gold", null)).toBe(10);
});

Test che l'IA suggerisce:

// Edge case 1: Cumulo sconti supera 100%
test("handles discount overflow", () => {
  const result = calculateDiscount(100, "platinum", "SUMMER2024");
  // 20% + 15% = 35% discount
  // Ma cosa succede se aggiungiamo altri sconti?
  expect(result).toBe(35);
  expect(result).toBeLessThanOrEqual(100); // Mai più del prezzo originale!
});

// Edge case 2: Valori estremi
test("handles very large order amounts", () => {
  const result = calculateDiscount(999999999, "gold", null);
  expect(Number.isFinite(result)).toBe(true);
});

// Edge case 3: Input inaspettati
test("handles invalid customer level gracefully", () => {
  expect(() => calculateDiscount(100, "diamond", null)).not.toThrow();
});

// Edge case 4: Promo code scaduto
test("rejects expired promo codes", () => {
  // Il codice attuale non verifica la data!
  // BUG TROVATO prima del deploy
});

// Edge case 5: Arrotondamento
test("rounds discount correctly to 2 decimals", () => {
  const result = calculateDiscount(33.33, "gold", null);
  expect(result).toBe(3.33); // Non 3.333333...
});

Test Driven Development Potenziato

L'IA può supportare anche il TDD classico:

  1. Descrivi il comportamento desiderato in linguaggio naturale
  2. L'IA genera i test case completi
  3. Esegui i test (tutti falliscono, come previsto)
  4. Implementa il codice minimo per farli passare
  5. Refactoring con confidenza (i test proteggono)

Test di Integrazione e E2E

L'IA può anche assistere in test più complessi:

  • Generare fixture e mock data realistici
  • Identificare scenari di integrazione critici
  • Suggerire test E2E user journey completi
  • Proporre strategie per testare race condition
  • Creare test di carico e stress realistici

Property-Based Testing

L'IA può suggerire "proprietà invarianti" da testare:

"Per qualsiasi input valido, la funzione encrypt(decrypt(x)) deve sempre restituire x"

Invece di testare casi specifici, testiamo proprietà matematiche che devono sempre valere.

Il Nuovo Workflow di Testing

  1. Sviluppo funzionalità
  2. IA genera test base (happy path + null handling)
  3. IA suggerisce edge case basati sull'analisi della logica
  4. Umano rivede e seleziona i test più critici
  5. Esecuzione e integrazione nella CI/CD
  6. Refactoring sicuro protetto dai test

Conclusioni

L'Avvocato del Diavolo trasforma la scrittura di test da una corvée tediosa a un'analisi del rischio intelligente e proattiva.

La scrittura di test cessa di essere una semplice ricerca della "copertura del codice" e diventa un'analisi sistematica di tutti i modi in cui il software può fallire.

Il risultato? Una rete di sicurezza molto più robusta, che permette ai team di muoversi velocemente mantenendo alta la qualità e la fiducia nel codice in produzione.