Piramide del Testing: la giusta proporzione tra Unit, Integration ed E2E

Il problema: test che ti fanno perdere tempo o che non trovano i bug

Hai una suite di test che impiega un'ora per finire. Oppure ne hai una che passa sempre, ma i bug arrivano in produzione. Entrambi i casi significano che la proporzione è sbagliata. Noi, di Meteora Web, lo vediamo spesso nei progetti che ci arrivano: chi scrive solo test end-to-end perché "sono quelli che simulano l'utente", e poi si ritrova con build da 40 minuti. Chi invece copre solo funzioni isolate con unit test, e scopre in produzione che i moduli non comunicano. La piramide del testing non è un dogma. È un termometro del rapporto tra velocità e affidabilità. Se la ignori, paghi in tempo perso o bug non rilevati.

Perché la piramide esiste

Immagina di avere un test che controlla l'intero flusso di acquisto: login, catalogo, carrello, checkout. Se fallisce, non sai subito se è il gateway di pagamento o un errore nel frontend. Per debug, ci perdi 20 minuti. La piramide ti dice: più test sono piccoli e veloci, più devono essere numerosi. I test grandi e lenti devono essere pochi. La proporzione classica è 70/20/10: unit 70%, integration 20%, E2E 10%. Ma la realtà è più sfumata, e dipende dal dominio.

Cosa succede se inverti la piramide

Un nostro cliente aveva una suite E2E per ogni funzionalità, zero unit test. Ogni modifica al CSS rompeva un test che riguardava un bottone lontano. Risultato: 3 ore di fix a settimana e fiducia zero. Abbiamo ribaltato la piramide: unit per la logica di business, integration per i servizi esterni mockati, E2E solo per i flussi critici. I test passavano in 5 minuti. Il morale del team è salito, i bug dropati.

Unit test: la base che regge tutto

Un unit test verifica una singola unità di codice — una funzione, un metodo — in isolamento. Deve essere veloce (millisecondi), deterministico (sempre lo stesso risultato) e senza dipendenze esterne (niente database, API, filesystem).

Esempio in JavaScript con Jest:

// funzione da testare
function calcolaSconto(prezzo, percentuale) {
  if (percentuale < 0 || percentuale > 100) {
    throw new Error('Percentuale non valida');
  }
  return prezzo - (prezzo * percentuale / 100);
}

// test
test('sconto del 20% su 100 euro dà 80', () => {
  expect(calcolaSconto(100, 20)).toBe(80);
});

Questo test parte in millisecondi, non ha bisogno di nulla. Se lo rompi, sai esattamente qual è la funzione colpevole.

Il limite dell'unit testing

Da soli non bastano. La funzione calcolaSconto potrebbe funzionare, ma se il frontend invia la percentuale come stringa o il backend non la chiama mai, il bug sfugge. Per questo servono test di integrazione.

Integration test: il collante tra i pezzi

I test di integrazione verificano che due o più moduli interagiscano correttamente. Spesso includono un database di test, un server HTTP in memoria, o mock di servizi esterni. Sono più lenti degli unit (secondi), ma molto più veloci degli E2E.

Esempio con Node.js, Express e supertest:

const request = require('supertest');
const app = require('../app');

describe('POST /api/ordini', () => {
  it('dovrebbe creare un ordine con dati validi', async () => {
    const res = await request(app)
      .post('/api/ordini')
      .send({ cliente: 'Mario', importo: 50 });
    expect(res.statusCode).toBe(201);
    expect(res.body.id).toBeDefined();
  });
});

Qui stiamo testando che il server risponda correttamente quando riceve una richiesta HTTP, che la validazione funzioni, che il dato finisca nel DB. Non serve un browser. Se il gateway di pagamento è un mock, il test rimane veloce e affidabile.

Attenzione: mock e stub

Non mockare tutto. Un errore comune è isolare talmente tanto i test che non testano più l'integrazione reale. Noi mockiamo solo i servizi che non controlliamo (API terze, email), e usiamo database reali in container Docker per il resto.

E2E test: il cruscotto della sanità mentale

I test end-to-end simulano l'utente reale: aprono un browser, cliccano, compilano form, aspettano risposte. Sono lenti (minuti), fragili (un cambio di classe CSS li rompe), e costosi da mantenere. Però danno la massima fiducia: se passano, il flusso funziona davvero.

Esempio con Cypress (configurazione minima):

describe('Flusso di acquisto', () => {
  it('completa un ordine', () => {
    cy.visit('/');
    cy.contains('Acquista').click();
    cy.get('input[name="email"]').type('test@example.com');
    cy.get('button[type="submit"]').click();
    cy.url().should('include', '/grazie');
  });
});

Questo test percorre tutta l'applicazione: frontend, API, database, eventuali servizi esterni. Costa caro: va eseguito solo sui flussi critici (checkout, login, registrazione).

La proporzione giusta: come calcolarla

Non esiste un numero magico universale, ma una regola empirica che funziona: ogni test che fallisce deve portarti all'errore in meno di 5 minuti. Se un test E2E fallisce e devi scavare in 10 file, sono troppi. Se un unit test fallisce e capisci subito il problema, è oro.

Parti da queste linee guida:

• Unit test: copri tutta la logica di business. Se una funzione ha condizionali, testa ogni ramo. Obiettivo: >80% di coverage sulle regole di business (non sul codice cosmetico).
• Integration test: copri ogni endpoint API e ogni interazione con il database. Almeno un test per flusso positivo e uno per errore atteso.
• E2E test: un test per journey critico (login, acquisto, registrazione). Massimo 10-15 test in totale.

Come adattare la piramide al tuo progetto

Se lavori su un'app con pochissima logica (es. solo CRUD), la proporzione si sposta verso integration ed E2E. Se invece hai un dominio ricco di regole (finanza, assicurazioni), gli unit test dominano. Noi, di Meteora Web, abbiamo costruito piattaforme proprietarie con Laravel: per i moduli di fatturazione (regole IVA, calcolo imponibile) scriviamo decine di unit test, mentre per il frontend Vue ci fermiamo a qualche integration test e un E2E per l'onboarding.

Errori comuni da evitare

• Test di implementazione: testare che una funzione chiami un'altra funzione interna invece di testare il comportamento. I test di implementazione si rompono a ogni refactoring e non aggiungono valore.
• Mock eccessivi: se un test di integrazione mocka anche il database, non è più un test di integrazione. Diventa un unit test mascherato.
• E2E onnipresenti: testare ogni bottone con Cypress porta a una suite lenta e fragile. Sii selettivo.
• Ignorare il setup: un test che richiede 30 secondi di fixture non sarà mai eseguito volentieri. Automatizza dati di test con factory e seed.

Strumenti pratici per iniziare

Per JavaScript/TypeScript: Jest o Vitest per unit, supertest per integration, Cypress o Playwright per E2E. Per PHP/Laravel: PHPUnit per unit e integration, Dusk per E2E. Per Python: pytest con pytest-django e Selenium o Playwright.

Un consiglio operativo: non scrivere test su feature che non esistono ancora. Aspetta di aver stabilito l'interfaccia, poi testala. E non inseguire il 100% di coverage in ogni file: concentrati sulle aree che generano fatturato — logica dei prezzi, calcolo spedizioni, integrazione pagamenti. Come diciamo sempre: "Un sito si misura in fatturato, non in complimenti." I test servono a proteggere quel fatturato.

In sintesi — cosa fare adesso

1. Analizza la tua suite attuale: conta quanti test di ogni tipo hai. Se il rapporto unit/integration/E2E è più di 1:1:1, hai un problema.
2. Sposta i test: trasforma gli E2E fragili in integration test robusti. I flussi semplici non hanno bisogno del browser.
3. Aggiungi unit test alle regole di business: individua le funzioni con condizionali, calcoli, validazioni. Scrivigli un test per ogni percorso.
4. Automatizza l'esecuzione: i test devono partire a ogni push (CI/CD). Se non hai una pipeline, inizia con GitHub Actions e un workflow minimo.
5. Misura il tempo di esecuzione: una suite che impiega più di 10 minuti viene eseguita sempre meno. Taglia gli E2E superflui.

La piramide del testing è uno strumento vivo. Non si applica uguale su un e-commerce e su un gestionale. Ma il principio è universale: testa tanto e velocemente ciò che è piccolo e centrale, testa poco e lentamente ciò che è grande e periferico. Noi la applichiamo ogni giorno sui progetti dei nostri clienti. Se vuoi vederla funzionare su un progetto reale, dai un’occhiata alla nostra guida sulle API — lì abbiamo integrato proprio questo approccio.