Piramide dei test

La piramide dei test (test pyramid) è una linea guida su come distribuire i test automatici tra i vari livelli. La base larga sono gli unit test, veloci, economici e precisi. Il centro sono i test di integrazione o di servizio. La punta stretta sono i test end-to-end attraverso la UI, che danno la fiducia più realistica ma sono i più lenti e fragili. L’idea, resa popolare da Mike Cohn, è spingere ogni verifica al livello più basso in grado di intercettare il problema.

Esempio

Prendi una regola: “gli ordini sopra i 100 $ hanno la spedizione gratuita”.

• Unit: testa la funzione del costo di spedizione con 99,99 $, 100,00 $ e 100,01 $. Millisecondi ciascuno, nessun browser.
• Integrazione/API: chiama POST /orders con un carrello da 120 $ e verifica che la risposta contenga shipping: 0. Questo dimostra che la regola è collegata al servizio.
• End-to-end: un solo test UI che completa il checkout con un carrello idoneo e vede “Spedizione gratuita” nella pagina di conferma.

Non ti servono dieci test UI per i valori limite. Gli unit test dimostrano già i calcoli.

Perché la forma conta

I test di livello più alto toccano più componenti, quindi un fallimento ti dice meno su dove si trova il bug. Hanno anche bisogno di browser, ambienti e dati di test, il che li rende più lenti e più soggetti a flakiness. Una suite fatta per lo più di test UI (l’anti-pattern del “cono gelato”) gira per ore, fallisce per motivi che non c’entrano con la modifica e finisce per essere ignorata.

Critiche e alternative

La piramide è un’euristica, non una quota. Alternative come il “testing trophy” danno più peso ai test di integrazione, sostenendo che unit test pieni di mock possono passare mentre il sistema reale è rotto. Entrambi i modelli concordano sulla parte importante: mantieni pochi test UI lenti e ampi, concentrati sui percorsi critici, e ricava la maggior parte della fiducia dai livelli più veloci. Scegli l’equilibrio in base a da dove arrivano davvero i tuoi bug, non in base a un rapporto fisso.