Mocking nei Test Automatizzati: Quando è utile e quando invece non lo è
Qualche settimana fa, tra una chiacchiera e l’altra, mi sono ritrovato a discutere con un mio collega dell’utilità del mocking dei dati per effettuare dei test automatizzati. Avevamo due pareri discordanti a riguardo: io sostenevo che, dove possibile, fosse meglio farne a meno prediligendo un puro end-to-end, mentre lui sosteneva che fosse una pratica fondamentale per avere dei test efficaci e coerenti e che senza non si possa davvero parlare di test automatizzati.
La verità? Avevamo entrambi torto ed entrambi ragione ed ora vi spiego il perchè. Ma partiamo prima dalle basi.
Cos’è il Mocking dei Dati?
Il mocking dei dati è una tecnica di testing automatizzato che consiste nel simulare o “mockare” i dati di input o le risposte di un servizio esterno. Questo permette di eseguire test in isolamento, senza dipendere da integrazioni esterne complesse. Ci sono però situazioni in cui il mocking, a mio avviso, può avere limitazioni. Iniziamo dagli aspetti positivi che hanno fatto del mocking una buona pratica in ormai numerosi contesti.
Quando è utile il mocking?
1. Test di unità e componenti isolati
Il mocking è particolarmente utile per i test di unità o di componenti isolati. In questi casi, l’obiettivo è verificare il comportamento di una singola funzionalità o componente senza considerare le integrazioni esterne. Mockare i dati consente di concentrarsi su un aspetto specifico del software senza toccare o vedere ciò che non deve interessarci.
2. Testing precoce nello sviluppo
Nelle fasi iniziali dello sviluppo, le integrazioni con servizi esterni potrebbero non essere ancora disponibili o stabili. Il mocking permette di iniziare il testing il prima possibile, senza attendere che tutti i servizi siano pronti. In questo scenario direi che il mocking non è nemmeno una buona prassi ma rappresenta un obbligo se si desidera testare automaticamente il software.
3. Test di errori e condizioni speciali
Il mocking può essere utilizzato per testare scenari di errore o condizioni speciali difficili da riprodurre con le integrazioni reali. Ad esempio, è possibile simulare risposte di errore da parte di un servizio per verificare come il software gestisce tali situazioni.
Ora passiamo invece ad una serie di limiti che il mocking può avere, limiti secondo i quali tale prassi non va adottata a prescindere (parliamo naturalmente del mio parere e delle osservazioni che ho fatto a riguardo) :
1. Le differenze tra ambiente di test e produzione
I mock non possono coprire tutte le possibili situazioni della produzione. Ci potrebbero essere differenze tra ciò che il mock prevede e ciò che accade effettivamente nei sistemi reali. Chi conosce bene il mondo della programmazione lo sa, non è concepibile calcolare tutti i possibili scenari se ci troviamo davanti un software davvero strutturato e ricco di integrazioni.
2. Test di Integrazione
Per valutare l’interazione tra diversi componenti o servizi, è necessario coinvolgere integrazioni reali quanto più possibile. Il mocking dovrebbe essere ridotto in tali test per garantire una visione più accurata del comportamento del software nelle varie interazioni con ogni integrazione disponibile. Non è una questione di “non è colpa mia ma del developer che lavora per l’altra azienda” ma di essere a conoscenza dei reali rischi che corre il business per il quale il software opera, a prescindere da chi sia il “colpevole” di turno.
3. Deresponsabilizzazione e distacco dal contesto reale
Mentre il mocking dei dati può essere una pratica utile nel testing automatizzato, esistono rischi associati a un suo uso eccessivo o scorretto. Uno dei rischi principali è la deresponsabilizzazione degli sviluppatori e dei tester, poiché il mocking può portare a un allontanamento dal contesto reale del software. Il mocking può far perdere di vista il contesto reale in cui il software opera. Quando i dati sono mockati, il software potrebbe sembrare funzionare correttamente nei test, ma potrebbero emergere problemi significativi una volta che il software viene deployato in un ambiente di produzione con dati reali e integrazioni effettive.
Come Mockare Responsabilmente?
1. Mantenere i mock aggiornati
Assicurarsi di aggiornare i mock in base all’evoluzione delle integrazioni esterne è indispensabile. Le modifiche nei servizi esterni possono influenzare il comportamento del software. Creare dei mock può essere una soluzione apparentemente rapida e vincente ma se non si sta al passo con l’integrazione equivale allo stringersi la mano da soli e complimentarsi con se stessi.
2. Verifica in un Ambiente di Integrazione
Prima del deployment in produzione, sarebbe necessario avere un ambiente di integrazione dove verificare sempre i risultati dei test. Ciò consente di rilevare problemi che potrebbero non emergere nei test basati su mock e dare un riscontro reale al 99%.
3. Mock ma non troppo!
E’ importante trovare un equilibrio tra l’uso del mocking e i test basati su dati e integrazioni reali. Mentre il mocking può semplificare i test iniziali e isolati, non dovrebbe mai sostituire completamente la verifica del comportamento del software nell’ambiente di produzione o di integrazione.
E quindi? Chi aveva ragione?
Il mocking dei dati è uno strumento prezioso nel testing automatizzato, ma deve essere usato con saggezza. È essenziale valutare il contesto e decidere quando è appropriato utilizzarlo. Bilanciare i vantaggi del controllo nell’ambiente di test con la necessità di verificare il comportamento reale del software nell’ambiente di produzione è fondamentale per garantire la qualità del software.
In conclusione posso affermare che come sempre non esiste una sola verità ma che lo scambio di pareri ed idee come quelle tra me ed il mio collega possano generare un enorme valore che ci insegna come poterci comportare in frangenti ed esigenze completamente diverse.
