Mockare un servizio che non controlli
Il caso è sempre lo stesso: il tuo flusso passa per un servizio che non è tuo, e non riesci a raggiungerlo. Oggi non hai la VPN, è giù, lo mantiene un altro team, o semplicemente non esiste ancora. Un mock sblocca il pomeriggio — ed è anche il modo più facile di passare una settimana a testare contro una bugia.
Prima di tutto: è un mock quello che ti serve?
La domanda che decide non è «riesco a raggiungere quel servizio?», ma «sto testando la sua risposta o la sto attraversando?».
| Situazione | Cosa usare | Perché |
|---|---|---|
| Ti serve che restituisca qualcosa perché il tuo flusso prosegua | Mock | Il suo contenuto non è ciò che verifichi; è una precondizione |
| Stai verificando come il tuo codice reagisce a ciò che restituisce | Il servizio reale | Uno stub ti dirà che va tutto bene, e non lo saprai |
| Insegui un difetto che compare solo contro il reale | L'ambiente condiviso | Il difetto vive nella differenza fra lo stub e l'originale |
| È un test di integrazione | Testcontainers o un doppio nel test | Il ciclo di vita lo governa il test, non tu |
| Il servizio non esiste ancora | Mock dal suo contratto | È il caso in cui il mock non può mentire: è l'unica fonte |
Il rischio che nessuno racconta: lo stub resta fermo
Un mock congela un contratto. Il servizio reale continua a cambiare, e il tuo stub non se ne accorge: campi nuovi che non restituisci, un codice d'errore che ora significa altro, un formato di data che è cambiato. Il tuo codice passa in locale e fallisce all'integrazione, che è esattamente il problema che il mock prometteva di evitare.
Due cose lo riducono parecchio, e nessuna delle due è «fare attenzione»:
- Genera lo stub dal contratto, non a memoria. Se c'è un OpenAPI, lo scheletro della risposta viene da lì e si rigenera quando il contratto cambia.
- Cattura chiamate reali il giorno in cui hai accesso, e trasformale in stub. Un esempio catturato non inventa nulla.
I quattro modi per montarlo
| Modo | Costo d'ingresso | Dove si rompe |
|---|---|---|
| Un server di stub (WireMock, MockServer) nel tuo compose | Un container in più e i suoi file di mapping | Bisogna comunque reindirizzarci l'URL del chiamante, nella configurazione di un repository altrui |
| Un finto servizio scritto a mano | Mezz'ora, ed è fatto | Diventa un progetto che nessuno mantiene e di cui nessuno sa di chi sia |
| Intercettare nel client HTTP del servizio stesso | Poco, se il framework lo consente | È codice finto dentro il tuo repository, e qualcuno lo committerà |
| Un mock integrato nell'orchestratore | Installare lo strumento | Lega l'ambiente locale a quello strumento |
Nota che tre dei quattro condividono lo stesso punto dolente, e non è scrivere lo stub: è far sì che chi chiama vada allo stub. Questo significa cambiare un URL nella configurazione di un repository che spesso non è tuo, e disfarlo quando vuoi tornare al servizio reale.
Come lo fa Aseptic
Aseptic tratta «dove chiama questa dipendenza» come una decisione di prima classe, non
come una modifica di file. Per ogni dipendenza scegli fra tre destinazioni —il servizio
locale, il tuo ambiente nel cloud o un mock— e il motore riscrive l'URL
all'avvio, iniettandolo come property -D o variabile d'ambiente.
Conseguenze pratiche:
- Il repository non si tocca. Niente da committare, niente da annullare, niente da rivedere in una pull request.
- Tornare indietro è cambiare la destinazione, non disfare una modifica. Puoi fare avanti e indietro fra mock e servizio reale più volte in un pomeriggio.
- Il resto dello scenario se ne accorge da solo: la decisione si prende una volta e la applicano tutti quelli che chiamano quel servizio.
Gli stub si definiscono nel Mock Studio: catturare una chiamata e trasformarla in stub con un clic, generare lo scheletro della risposta da un OpenAPI, e organizzare varianti per servizio —la risposta felice, quella che dà 404, quella lenta— con hot reload, senza riavviare niente.
Quello che un mock non ti darà
Va detto qui, perché è dove si perde tempo: se il difetto che insegui vive nel servizio reale —un header che aggiunge il gateway, un payload che nessuno ha documentato, il comportamento sotto carico— il mock non lo riprodurrà, per definizione. Lì quello che serve è raggiungere l'ambiente condiviso, e se il tuo sistema è troppo grande per la tua macchina, il confronto con Telepresence spiega l'altro approccio.
I passi concreti sono in mockare una dipendenza, e se quello che ti blocca è dover avviare troppe cose, la pagina su avviare solo parte del sistema.
Domande frequenti
Quando conviene mockare un servizio e quando no?
Mockalo quando la sua risposta non è ciò che stai testando: ti serve perché il tuo flusso proceda, non per verificarla. Non mockarlo quando ciò che vuoi verificare è proprio come il tuo codice reagisce a ciò che quel servizio restituisce davvero —lì uno stub ti dirà che va tutto bene e non sarà vero—.
Un mock non finisce per mentirmi?
Può, ed è il suo rischio reale: lo stub congela un contratto che dall'altra parte continua a cambiare. Si mitiga generandolo dall'OpenAPI del servizio invece che a mano, e catturando chiamate reali quando riesci a raggiungerlo.
Come passo dal servizio reale al mock senza modificare i miei repository?
Con Aseptic è una decisione per dipendenza: scegli locale, cloud o mock e l'URL viene riscritto all'avvio, iniettato come configurazione. Il file del repository resta esattamente com'è in git.
Devo scrivere lo stub a mano?
Non necessariamente. Si può generare lo scheletro della risposta da un OpenAPI, oppure catturare una chiamata reale l'unica volta in cui avevi accesso e convertirla in stub con un clic.