Testing

Un test per place_order ha bisogno di un gateway di pagamento, un client SMS e un calcolatore delle tasse. Se collegassi quelli veri, ogni esecuzione del test addebiterebbe una carta e manderebbe un SMS a un numero reale. Un test unitario deve girare in pochi millisecondi, senza rete, quindi tutti e tre vanno sostituiti con qualcos’altro. Quel “qualcos’altro” si presenta in cinque forme — ognuna risolve un problema diverso — e trattarle come intercambiabili è il motivo per cui le discussioni “basta mockarlo” in code review girano in tondo. ...

Un test scritto dopo il codice tende a verificare quello che il codice fa, non quello che doveva fare. Il test-driven development risolve il problema invertendo l’ordine: scrivi il test, guardalo fallire, poi scrivi il minimo codice che lo fa passare. Dato che il test esiste prima del codice che controlla, non può confermare silenziosamente qualunque cosa il codice restituisca. Kent Beck ha formalizzato questo ciclo come red, green, refactor nel suo libro del 2002 Test-Driven Development: By Example. Il nome è rimasto. ...

Una funzione può avere il 100% di copertura dei test unitari e la pagina che la chiama può comunque restituire un 500 in produzione. Non è una contraddizione. Test unitari, test di integrazione e test end-to-end controllano cose diverse, e una suite pesante su uno e leggera su un altro ha un buco specifico e prevedibile. Cosa controllano test unitari, di integrazione ed end-to-end Prendi una funzionalità di registrazione: una funzione valida l’input, scrive una riga su un database e invia un’email di benvenuto. Tre test possono coprirla, e ognuno risponde a una domanda diversa. ...