Il telefono vero ha sempre ragione: test su dispositivo reale

Quando si sviluppa con un agente di coding, la domanda più importante non è "funziona?" ma "chi l'ha verificato, e su cosa?". Un emulatore di iPhone non è un iPhone: può dire che una pagina funziona mentre sul telefono vero è rotta. Lo abbiamo visto con il sito di Sweet Pal, e da allora per certi bug il test su dispositivo reale è il primo passo, non l'ultimo.

Sulla home di sweetpal.ai c'è una sezione che chiamiamo stage. Scorrendo, l'immagine dell'iPhone resta ferma sotto l'intestazione e le schermate dell'app cambiano una dopo l'altra, insieme al testo accanto. Tecnicamente è un blocco con position: sticky dentro un contenitore alto qualche schermo, più un po' di JavaScript che sceglie la schermata in base a quanto si è scorso. Sul computer funzionava. Una sera è arrivato il messaggio che nessuno vuole leggere: "il parallasse non funziona su mobile". Sul telefono vero, il telefono disegnato scorreva via insieme al resto della pagina invece di restare agganciato.

Abbiamo chiesto all'agente di trovare la causa, e il suo lavoro è stato metodico. In locale il sito non partiva con i dati veri, quindi ha provato direttamente su sweetpal.ai con un browser automatizzato che simula un iPhone. Prima con Chromium, il motore di Chrome: lo stage si agganciava. Poi con WebKit, il motore di Safari, per avvicinarsi al telefono vero: si agganciava anche lì. Poi con gli screenshot, per guardare cosa si vedeva davvero e non solo i numeri: le schermate avanzavano una dopo l'altra. Restava un dubbio, perché per comodità saltava il muro del consenso ai cookie impostando la scelta in anticipo, e quel muro tocca lo scroll della pagina; così l'ha rifatto passando dal muro, cliccando il bottone come farebbe una persona. Stesso risultato. A quel punto la conclusione facile sarebbe stata "non riesco a riprodurlo, sul mio ambiente va". L'emulazione aveva dato quattro volte la stessa risposta, ed era sbagliata quattro volte.

Quando non si riproduce, si ragiona sulle cause note

La mossa giusta è stata cambiare metodo. Se il bug non si fa vedere, si smette di cercarlo provando e si comincia a cercarlo leggendo: si risale la catena dei contenitori dello stage, uno per uno, cercando qualcosa che sul motore di Safari per iPhone sia noto per rompere position: sticky. Ce n'era uno solo fuori posto, nel foglio di stile globale condiviso con la documentazione tecnica:

body { overflow-x: hidden; }

Era stato messo lì per la documentazione, e sul sito nessuno ci pensava più. È una causa nota: un antenato con overflow diverso da visible diventa il contenitore di scorrimento di riferimento per gli elementi sticky, e su Safari iOS basta questo perché lo sticky non si agganci dove ci si aspetta. Il sito, oltretutto, non ne aveva bisogno: il suo contenitore principale taglia già quello che sporge con overflow-x: clip, che a differenza di hidden non crea un contenitore di scorrimento. La correzione è stata una riga, limitata alle pagine del sito, body:has(.sp-site) { overflow-x: visible; }, e la documentazione è rimasta com'era. L'agente ha controllato anche il rischio opposto, cioè che con l'overflow libero una pagina larga 320 pixel cominciasse a scorrere di lato: home, versione inglese, le tre landing, contatti e privacy, nessuno scorrimento orizzontale.

La parte che ci interessa di più è come ha riportato il risultato. Non ha scritto "risolto". Ha scritto che la correzione era ancora da verificare, perché in emulazione il problema non si riproduceva e quindi non poteva confermare di averlo tolto; sull'iPhone vero lo scorrimento lo governa il sistema, mentre l'emulatore lo simula dentro un browser sul computer. E non ha pubblicato da solo, perché sul sito un push sul ramo principale va in produzione in pochi minuti. Ha chiesto di provare su un iPhone vero e, se non fosse bastato, di dire cosa si vedeva esattamente: il telefono scorre via, oppure resta fermo ma le schermate non cambiano? E con quale browser? Sono due bug diversi, con due cause diverse. La risposta è stata "pubblica che controllo". Commit, ricostruzione del sito, e un consiglio prima di provare: ricaricare forzando la cache, perché Safari poteva mostrare ancora il foglio di stile vecchio e far sembrare inutile una correzione giusta. Poco dopo: "ha funzionato".

Cosa abbiamo imparato

Il bug in sé era banale, una riga di CSS. Le lezioni no. L'emulazione emula il motore, non il dispositivo: per lo scorrimento, lo sticky e tutto quello che dipende da come il sistema gestisce il dito sullo schermo, un "funziona" vuol dire soltanto "funziona in emulazione". Se il bug non si riproduce, continuare a provare nello stesso ambiente produce solo altre conferme sbagliate; per Safari iOS le cause note di uno sticky che non si aggancia sono poche e documentate, e si controllano tutte risalendo i contenitori.

Un risultato non verificato si dichiara come tale: "ho applicato una correzione, ma è da verificare" vale più di un "risolto" ottimista, perché dice dove sta l'incertezza e chi può toglierla. E spesso chi può toglierla è la persona, perché il dispositivo vero ce l'ha lei: nel lavoro con un agente la verifica più economica è prendere il telefono in mano, e conviene chiederla subito, con una domanda precisa, invece che dopo un'ora di tentativi. Le correzioni restano piccole e con il rischio opposto controllato, così se fossero sbagliate sarebbe facile toglierle. Infine, quello che si è imparato si scrive: l'agente ha annotato nella sua memoria di progetto che per questo genere di bug l'emulazione non basta e che la prossima volta si parte dalle cause note di Safari iOS. Una lezione che resta solo nella conversazione si perde alla sessione successiva.

In sintesi:

• Un emulatore di iPhone, anche con il motore di Safari, può dire "funziona" su bug di scorrimento e sticky che sul telefono vero ci sono.
• La causa era body { overflow-x: hidden }, nota per rompere position: sticky su Safari iOS; la correzione è stata una riga limitata al sito.
• Quando un bug non si riproduce, si cercano le cause note invece di ripetere le prove nello stesso ambiente.
• Un lavoro non verificato si riporta come "da verificare", con una domanda precisa per chi ha il dispositivo in mano.
• Le lezioni vanno scritte dove la sessione successiva le ritrova.