Svuotare la cache del browser su Mac per i test QA: la scala di reset
Svuotare la cache del browser su Mac per i test QA: la scala di reset
Risposta rapida: Per svuotare la cache del browser su Mac nei test QA, sali la scala dal reset più leggero a quello più pesante: ricaricamento forzato, «Disable cache» negli strumenti per sviluppatori, eliminazione dei dati del sito (cookie, storage, service worker) e, infine, un profilo usa e getta nuovo di zecca. Cancellare le cartelle della cache sul disco risolve solo i file obsoleti. Non azzera le sessioni di login né lo stato dell’app.
Segnali un bug. Lo sviluppatore risponde: «Da me funziona». Rifai il test e, all’improvviso, funziona anche da te. Non è cambiato nulla, tranne il fatto che il browser ha servito in silenzio una copia fresca di un file che teneva da parte.
Il lavoro di QA su Mac ha un problema particolare con le cache: devi sapere con precisione contro quale livello di stato memorizzato stai testando. «Svuota la cache» è un’istruzione troppo grossolana per questo. Questa guida divide lo stato memorizzato del browser in livelli e indica, per ciascuno, il reset più piccolo che funzioni.
Cosa è davvero bloccato? Associa il sintomo al livello giusto
I browser conservano diversi tipi di stato, e «la cache» è solo uno di questi.
Sintomo Livello probabile Soluzione più leggera CSS/JS vecchi dopo un deploy Cache HTTP Ricaricamento forzato Le modifiche non compaiono, ma solo nella finestra normale Cache HTTP o service worker DevTools con cache disattivata, poi annullare la registrazione del service worker Risulti ancora connesso come l’utente sbagliato Cookie / storage Eliminare i dati del sito per quell’origine Un feature flag o lo stato dell’onboarding non si azzera localStorage / IndexedDB Eliminare i dati del sito L’app funziona offline quando non dovrebbe Service worker + Cache Storage Annullare la registrazione del service worker ed eliminare i dati del sito Il bug non si riproduce sul computer di un collega Stato accumulato nel profilo Profilo nuovo
Parti dall’alto della scala e scendi solo se il problema persiste. Ogni piolo in più butta via altro stato che potrebbe servirti per riprodurre il bug.
Piolo 1: ricaricamento forzato (pochi secondi, nessuna perdita di dati)
Un ricaricamento forzato aggira la cache per il caricamento corrente della pagina.
Chrome, Edge, Firefox: ??R Safari: ??R («Ricarica senza contenuti in cache» / «Ricarica dall’origine»)
Risolve la lamentela più comune, quella della «build vecchia». Non tocca cookie, storage né service worker, e vale solo per quel caricamento: le risorse richieste più tardi possono ancora arrivare dalla cache.
Piolo 2: far aggirare la cache agli strumenti per sviluppatori mentre testi
Se ricaricherai tutto il pomeriggio, smetti di farlo a mano.
Chrome/Edge: apri gli strumenti per sviluppatori ? scheda Network ? spunta Disable cache. Vale solo finché gli strumenti restano aperti. Firefox: DevTools ? Rete ? Disattiva cache HTTP (a toolbox aperta). Safari: attiva prima il menu Sviluppo (Safari ? Impostazioni ? Avanzate ? «Mostra funzionalità per sviluppatori web», la dicitura varia a seconda della versione), poi usa Sviluppo ? Disattiva cache.
Chrome offre anche una scorciatoia comoda: con gli strumenti aperti, clic destro sul pulsante di ricarica e scegli «Svuota la cache e ricarica forzatamente».
Una trappola in cui cadono in molti: «Disable cache» non annulla la registrazione dei service worker. Un service worker può continuare a servire le proprie risposte memorizzate. Se il piolo 2 non basta, passa al 3.
Piolo 3: elimina i dati del sito per una sola origine
Cancellare tutto è raramente ciò che vuoi. Limitare il reset al sito in prova ti lascia intatte le altre sessioni (e i nervi).
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Prima di cliccare, controlla cosa è spuntato: cookie, storage locale e di sessione, IndexedDB, Cache Storage e service worker si possono includere o escludere singolarmente. Il pannello Service Workers consente anche di annullare direttamente la registrazione di un worker e offre l’opzione Update on reload.
Firefox: Impostazioni ? Privacy e sicurezza ? Cookie e dati dei siti ? Gestisci dati, poi rimuovi il sito specifico. In alternativa, usa la scheda Storage degli strumenti per sviluppatori.
Safari: Impostazioni ? Privacy ? Gestisci dati dei siti web, cerca il dominio e rimuovilo.
È il reset giusto per «bloccato sull’utente sbagliato», feature flag obsoleti e bug della modalità offline. È anche il piolo in cui conviene annotare cosa hai cancellato, perché «ho eliminato i dati del sito» e «ho svuotato solo la cache HTTP» possono dare risultati di test diversi.
Piolo 4: un profilo usa e getta (il reset riproducibile)
Quando devi dimostrare che un bug non dipende dal tuo stato accumulato, non ripulire il vecchio profilo: ricomincia da uno pulito.
Opzioni rapide:
Una finestra privata/in incognito (nessuno stato persistente, ma le estensioni sono spesso disattivate, il che altera il test). Un profilo Chrome temporaneo dal Terminale: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Ogni nuovo percorso crea un profilo vergine, senza cookie, senza cache e senza estensioni. Elimina la cartella a fine test oppure tienila come baseline con nome per uno specifico piano di test.
È la risposta più netta a «è l’app o è il mio browser?». Ed è il modo migliore per passare a qualcun altro passaggi di riproduzione che partono da uno stato noto.
Dove vive la cache sul disco (e perché conviene ripulirla)
Tutto quanto sopra agisce su uno stato gestito dal browser stesso. Separatamente, le cartelle della cache si accumulano sul disco, cosa che conta se lavori tutto il giorno con più browser e build di test. Percorsi tipici nella cartella Libreria del tuo utente:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/