Hai mai lanciato una modifica in produzione e scoperto, dopo ore, che un dettaglio banale ha rotto tutto? Noi sì. E ogni volta ci siamo chiesti: perché non abbiamo scritto un test prima?
Il testing del software non è una perdita di tempo. È il modo con cui un progetto smette di essere fragile e diventa affidabile. Noi di Meteora Web lavoriamo da anni su stack eterogenei – WordPress, Laravel, React – e abbiamo visto progetti morire per mancanza di test. Altri crescere perché i test erano parte del DNA del codice.
Questa pillar page copre tutto ciò che serve per impostare una strategia di testing del software solida, dal singolo sviluppatore alla pipeline CI/CD. Nessuna teoria astratta: solo ciò che funziona davvero.
Perché il testing del software è il miglior investimento per un progetto?
Spesso sentiamo dire: “Il cliente non paga per i test, paga per le funzionalità”. È vero solo in apparenza. Un bug in produzione costa molto più del tempo speso a prevenirlo. Il testing del software è una forma di assicurazione. Paghi un premio oggi per evitare un disastro domani.
Noi lo abbiamo imparato sulla nostra pelle: un cliente e-commerce aveva un form di checkout che in determinate condizioni generava un errore 500. Il problema emerse in produzione, con ordini persi e assistenza da gestire. Un test di integrazione avrebbe beccato il bug in 5 minuti.
Cosa si ottiene con un buon testing
- Riduzione dei bug in produzione – meno incidenti, meno chiamate notturne.
- Refactoring sicuro – si può modificare il codice sapendo che i test lo proteggono.
- Documentazione vivente – i test spiegano cosa il sistema deve fare.
- Meno ansia nei deploy – la pipeline automatica ti dice se va tutto bene.
Se non hai ancora iniziato, il momento migliore è adesso. Il secondo momento migliore è dopo aver letto questa guida.
Sponsored Protocol
Come bilanciare unit, integration e E2E nel testing del software?
La piramide del testing è il modello più noto: tanti test unitari alla base, meno test di integrazione, ancora meno test end-to-end. La proporzione ideale? Circa 70% unit, 20% integration, 10% E2E. Ma non è una legge scolpita nella pietra. Dipende dal contesto.
Unit test – la base solida
Testano una singola funzione o metodo, isolato da tutto il resto. Sono veloci, facili da scrivere e danno feedback immediato. Con Jest o PHPUnit si scrivono in pochi secondi. Esempio:
function somma(a, b) {
return a + b;
}
test('somma due numeri positivi', () => {
expect(somma(2, 3)).toBe(5);
});Integration test – il collante
Verificano che più componenti lavorino insieme: database, API, servizi esterni. Sono più lenti degli unit test, ma scoprono problemi reali. Noi li usiamo molto su Laravel con PHPUnit e database di test.
E2E test – la simulazione utente
Testano l'intero flusso come farebbe un utente. Strumenti come Playwright o Cypress lanciano il browser e interagiscono con l'app. Sono i più lenti e fragili, ma insostituibili per verificare che il sistema funzioni davvero.
Un errore comune è concentrarsi solo sugli E2E. Noi vediamo aziende che spendono budget enormi per test end-to-end trascurando gli unit test. Risultato: suite lenta, test che si rompono per qualsiasi refuso nel selettore CSS. La piramide va rispettata: più unit, meno E2E.
Quali strumenti scegliere per il testing del software in JavaScript e PHP?
Ogni ecosistema ha i suoi protagonisti. Ecco quelli che usiamo quotidianamente in produzione.
JavaScript / TypeScript
- Jest – il più diffuso per React, Node.js, Vue. Ha snapshot, mocking integrato, coverage. Le nostre scelte per progetti Laravel + Vue.
- Vitest – più veloce di Jest, nativo per Vite. Noi lo preferiamo nei progetti nuovi.
- Playwright – E2E cross-browser. Supporta Chromium, Firefox, WebKit. Test parallelizzati, retry automatico, debugging via trace viewer.
PHP
- PHPUnit – lo standard de facto. Usato da Laravel, Symfony, Magento. Affidabile, maturo, con data provider e mocking.
- Pest – alternativa elegante a PHPUnit, sintassi più pulita. Noi lo usiamo in nuovi progetti Laravel perché riduce boilerplate.
- Laravel Dusk – E2E per Laravel, ma meno performante di Playwright. Preferiamo Playwright anche per app Laravel.
La scelta giusta
Non esiste lo strumento perfetto. Noi consigliamo: Jest (o Vitest) per unit/integration in frontend, PHPUnit (o Pest) per backend PHP, Playwright per E2E. Poi valuta mutation testing con Stryker per capire se i tuoi test sono robusti.
Sponsored Protocol
TDD: Red, Green, Refactor – un mantra che funziona
Il Test-Driven Development è semplice: prima scrivi un test che fallisce (Red), poi scrivi il codice minimo per farlo passare (Green), infine migliori il codice (Refactor). Sembra lento? All'inizio sì, poi diventa più veloce del coding senza test.
Noi usiamo TDD quando la logica è complessa o quando il refactoring sarà frequente. Ad esempio, su un modulo di calcolo prezzi con sconti e tasse: scriviamo prima i casi limite, poi implementiamo. Il test diventa la specifica.
Esempio pratico in JavaScript
// Red: scriviamo un test che fallisce
test('calcola sconto del 10%', () => {
expect(calcolaSconto(100)).toBe(90);
});
// Green: implementazione minima
function calcolaSconto(prezzo) {
return prezzo * 0.9;
}
// Refactor: estraiamo costante
const SCONTO = 0.1;
function calcolaSconto(prezzo) {
return prezzo * (1 - SCONTO);
}Quando usarlo
TDD non è utile per tutto. Per interfacce utente o integrazioni con servizi esterni, spesso conviene scrivere prima il codice e poi i test. Ma per logica di dominio, algoritmi, regole di business, TDD è una garanzia.
Sponsored Protocol
Mock, stub e spy: isolare il codice senza dolore
Quando fai unit test, non vuoi dipendere da database, API esterne o file system. Entrano in gioco i doppi di test.
- Stub – forniscono risposte predefinite. “Quando chiami questo metodo, torna sempre 42”.
- Mock – verificano che un metodo sia stato chiamato con certi argomenti. “Controlla che il servizio email sia stato invocato con l'indirizzo giusto”.
- Spy – registrano le chiamate per ispezionarle dopo. Simili ai mock ma meno intrusivi.
Noi usiamo i mocking nativi di Jest e PHPUnit. Attenzione: abusare dei mock rende i test falsi. Se devi mockare metà del sistema, forse il test è troppo a basso livello o il design è accoppiato male.
Test di performance: k6 e Artillery per non andare in crash
Un sito può funzionare benissimo con un utente, e crollare con mille. I test di carico (load testing) simulano traffico reale per scoprire colli di bottiglia.
- k6 – moderno, scrivibile in JavaScript, produce report dettagliati. Noi lo integriamo nella CI per verificare che una nuova feature non degradi le performance.
- Artillery – YAML/JS, facile da configurare, buono per test di stress su API o WebSocket.
Esempio di script k6:
import http from 'k6/http';
import { sleep } from 'k6';
export default function () {
http.get('https://tuo-sito.com/api/prodotti');
sleep(1);
}
export const options = {
vus: 10,
duration: '30s',
};Eseguilo con k6 run script.js. Vedi i percentili di latenza, errori, throughput. Se il P95 supera i 2 secondi, hai un problema.
Sponsored Protocol
Mutation testing: Stryker per test che valgono davvero
La copertura del codice (code coverage) è un indicatore parziale. Un test può coprire il 100% delle righe ma non testare nulla di significativo. Il mutation testing modifica il codice (inserisce bug) e vede se i test lo rilevano. Se non lo rilevano, il test è debole.
Stryker è lo strumento principale per JavaScript e TypeScript. Esiste anche per PHP (Infection). Noi lo eseguiamo periodicamente su progetti critici. Esempio di comando:
npx stryker runStryker produce un rapporto con la percentuale di “mutanti uccisi”. Obiettivo: > 90% uccisi. Se è basso, i test non stanno proteggendo il codice come dovrebbero.
BDD con Cucumber: quando il comportamento conta più del codice
Il Behavior-Driven Development allinea sviluppatori, tester e stakeholder. Si scrivono scenari in linguaggio Gherkin: Given, When, Then. Poi si implementano i passi con codice.
Feature: Login
Scenario: Login riuscito
Given un utente registrato con email "mario@example.com"
When accede con password corretta
Then viene reindirizzato alla dashboardI test diventano leggibili da chiunque. Noi usiamo Cucumber con Playwright per E2E: scenari Gherkin che eseguono azioni nel browser. Non è adatto per unit test, ma per flussi di business è potente.
Come integrare il testing del software in una pipeline CI/CD?
Un test eseguito manualmente vale poco. Deve essere automatico, lanciato a ogni push. GitHub Actions è la nostra scelta per progetti PHP, Node.js o misti.
Esempio di workflow per Laravel
name: Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: '8.3'
extensions: mbstring, pdo_mysql
- run: composer install
- run: cp .env.example .env
- run: php artisan key:generate
- run: php artisan migrate --env=testing
- run: php vendor/bin/phpunitPer progetti frontend: npm test e poi npx playwright test. Inseriamo più job paralleli per unit, integration e E2E. I test E2E possono essere eseguiti solo su branch protetti per risparmiare risorse.
Sponsored Protocol
Cosa fare adesso
Non devi implementare tutto in un giorno. Ecco una sequenza pratica:
- Inizia con un test per la prossima funzionalità – scegli un modulo critico e scrivi un test unitario. Se non hai mai testato, parte con un test semplice.
- Misura la copertura – installa Jest o PHPUnit con coverage. Guarda le parti scoperte. Non inseguire il 100%, ma copri le funzioni più critiche.
- Aggiungi un test di integrazione – verifica che una rotta API funzioni con database reale (in memoria).
- Imposta la CI – configura GitHub Actions per eseguire i test a ogni push. Non accettare PR con test falliti.
- Dopo un mese, aggiungi mutation testing – Stryker o Infection ti diranno se i tuoi test sono solidi.
- Pianifica un test E2E per il flusso principale – con Playwright, simula il percorso più usato dagli utenti.
Il testing del software non è un costo: è l'investimento che trasforma il codice da una scatola fragile in un motore affidabile. Noi di Meteora Web lo facciamo ogni giorno. Se hai bisogno di una consulenza per impostare la tua strategia di test, contattaci.
