Pipeline verde per sei settimane, checkout rotto per due

Per due settimane i clienti in Ontario non potevano chiudere un acquisto, mentre la dashboard di CI mostrava solo verde da sei settimane¹.

La suite sembrava solida: circa l’80% di line coverage, qualche centinaio di unit test e una pipeline sotto i quattro minuti. Il modulo delle tasse aveva 40 test, tutti passavano¹.

Dopo un refactor del form indirizzo, il frontend ha iniziato a inviare la provincia come codice a due lettere nel campo region, non più in province. Il backend è caduto su un default. Il default non aveva una regola fiscale per l’Ontario. La validazione ordine ha rifiutato il totale¹.

Gli unit test erano corretti. Da lì è nata una domanda guida: se questo test passa, che cosa può fare un utente? Un test unitario raramente sblocca un’azione diretta. Un test funzionale sì: “con un indirizzo dell’Ontario, l’utente invia il carrello e riceve una conferma ordine con il totale giusto”¹.

La ricostruzione è partita dal ticket dei requisiti. L’autore ha elencato ogni frase con “should”. Erano 23. Alcune hanno richiesto varianti. Il totale è arrivato a circa 60 casi¹.

I test hanno esercitato l’API. Il checkout espone endpoint REST. Le nuove prove inviavano richieste HTTP a un’istanza reale del servizio con database seedato. Validavano il contratto usato dal frontend: nomi dei campi, codici di stato, forma degli errori, risultato di business. Il bug region vs province sarebbe caduto subito, perché il totale in risposta sarebbe stato sbagliato¹.

Ogni caso verificava almeno un esito visibile a una persona. Totale dell’ordine. Testo del messaggio di errore. Presenza di un job email in coda. Controllare solo un 200 è un ping, non un test funzionale¹.

Questo strato è costato. La suite funzionale ha portato il tempo di pipeline a circa 9 minuti, più del doppio. Le prime due settimane hanno visto test flaky causati da timestamp nei dati seed. Hanno risolto congelando il tempo nell’ambiente di test. La manutenzione ha pesato di più. Scrivere payload e risposte attese per 60 casi è tedioso. Ogni cambio API obbliga a toccare molti JSON¹.

Hanno provato tre strade. Suite scritte a mano in pytest usando requests. Pact per il contratto tra frontend e backend. Keploy per registrare il traffico reale e trasformarlo in test. Non c’è stato un vincitore assoluto. Pact ha funzionato bene per il contratto del frontend. Il traffico registrato ha aiutato sugli endpoint con payload annidati e scomodi da scrivere. Pytest è rimasto il migliore per gli edge case costruiti ad hoc¹.

Gli effetti si sono visti. In otto mesi la suite funzionale ha intercettato 11 bug prima della produzione. Sette con la stessa forma del caso Ontario: tutti gli unit passavano, ma il cablaggio tra componenti era sbagliato. Due erano problemi di configurazione emersi solo leggendo variabili d’ambiente reali. Due erano errori dell’autore. Anche la code review è cambiata. A ogni PR si chiede quale caso funzionale la copre. Se non c’è, si aggiunge o si spiega perché manca¹.

La nota finale dell’autore è secca: la coverage indica quanto codice gira, non se un cliente può comprare, e se non hai mai avuto un incidente del genere potresti essere solo fortunato¹.