Mock LocationTest della posizione: simulare le coordinate per QA e sviluppatori
La logica legata alla posizione è una delle più scomode da testare: il bug si riproduce in un punto preciso di una città mentre il team lavora in un’altra. La simulazione della posizione trasforma questo controllo in uno scenario ripetibile da eseguire dalla scrivania tutte le volte che serve. Vediamo come funziona su un dispositivo reale e dove sono i suoi limiti.
Prepara il dispositivo
Attiva la modalità sviluppatore, seleziona l’app per posizioni fittizie e concedile l’accesso alla posizione. Sui dispositivi di test conviene togliere subito i limiti in background: altrimenti la ROM chiuderà il servizio a metà di un test lungo.
Crea una serie di punti di riferimento
Salva nei preferiti le coordinate che ti servono regolarmente: l’indirizzo di un bug report, un punto al limite di una zona di consegna, un indirizzo in un altro fuso orario, un punto in mezzo all’acqua. Un elenco con nomi di punti riproducibili è la base di test ripetibili.
Sincronizza la serie con il team
L’elenco dei luoghi si sincronizza tra il sito e i dispositivi tramite l’account: i punti creati sul sito compaiono subito sui telefoni di test, senza copiare le coordinate a mano. Con più dispositivi si risparmia molto tempo.
Esegui lo scenario e registra il risultato
Attiva la simulazione nel punto giusto ed esegui lo scenario nell’app in test. Il punto resta nella cronologia, così ci torni con un tocco quando ricontrolli dopo una correzione.
Cosa verificare per forza
I bordi delle zone: un punto esattamente sul limite di una zona di consegna o di un raggio di ricerca è una fonte classica di errori di confine. Il cambio di coordinate mentre l’app è in esecuzione: molte app chiedono la posizione una volta all’avvio e non reagiscono ai cambiamenti. L’assenza di coordinate: il comportamento con la localizzazione spenta e con l’autorizzazione negata.
A parte, i dati volutamente non validi: un punto in mezzo all’oceano, coordinate nell’altro emisfero, luoghi senza indirizzo. In nessuno di questi casi l’app deve bloccarsi.
Dispositivo reale o emulatore
L’emulatore di Android Studio può impostare coordinate e riprodurre percorsi, e per le prime fasi di sviluppo basta. Ma non riproduce ciò che si rompe più spesso: come una ROM specifica chiude i servizi in background, il funzionamento con segnale debole, i ritardi reali nell’ottenere una rilevazione e le differenze nei criteri di risparmio energetico dei produttori.
Quindi uno scenario superato sull’emulatore va ricontrollato su un dispositivo reale, soprattutto se l’app in test usa la posizione in background.
Il contrassegno di fonte fittizia nei test
Android contrassegna le coordinate di un provider di test. Per il QA non è un ostacolo ma un aspetto da testare a parte: se l’app in test deve rifiutare le coordinate fittizie, la simulazione è proprio il modo per assicurarsi che il controllo funzioni davvero e non sia solo scritto.
Se l’app deve accettare qualsiasi coordinata dal sistema, assicurati che non le scarti per errore a causa di questo contrassegno.
Test di app con posizione in background
Per le app che tracciano gli spostamenti in background contano i test lunghi: attiva la simulazione, riduci a icona l’app e lascia il dispositivo per qualche ora. Così emergono problemi che non vedi in cinque minuti di test manuale: un’iscrizione agli aggiornamenti persa, errori che si accumulano, la ROM che ferma il servizio.
La notifica permanente nell’area notifiche fa da indicatore: finché c’è, la simulazione è attiva.