Mock LocationTestowanie lokalizacji: zmiana współrzędnych dla QA i programistów
Logika zależna od lokalizacji to jedna z najbardziej niewygodnych rzeczy do testowania: błąd odtwarza się w konkretnym punkcie miasta, a zespół siedzi w innym. Zmiana lokalizacji zamienia taką kontrolę w powtarzalny scenariusz, który można uruchamiać przy biurku tyle razy, ile trzeba. Zobaczmy, jak to działa na prawdziwym urządzeniu i gdzie są granice.
Przygotuj urządzenie
Włącz tryb programisty, wybierz aplikację do pozorowania lokalizacji i daj jej dostęp do lokalizacji. Na urządzeniach testowych warto od razu zdjąć ograniczenia pracy w tle — inaczej system zamknie usługę w połowie długiego testu.
Utwórz zestaw punktów referencyjnych
Zapisz w ulubionych współrzędne, których regularnie potrzebujesz: adres ze zgłoszenia błędu, punkt na granicy strefy dostawy, adres w innej strefie czasowej, punkt na środku wody. Lista odtwarzalnych punktów z nazwami to podstawa powtarzalnych testów.
Zsynchronizuj zestaw z zespołem
Lista miejsc synchronizuje się między stroną a urządzeniami przez konto: punkty dodane na stronie od razu pojawiają się na telefonach testowych, bez ręcznego przepisywania współrzędnych. Przy kilku urządzeniach oszczędza to mnóstwo czasu.
Uruchom scenariusz i zapisz wynik
Włącz symulację we właściwym punkcie i przejdź scenariusz w testowanej aplikacji. Punkt zostaje w historii, więc przy ponownym sprawdzeniu po poprawce wrócisz do niego jednym dotknięciem.
Co koniecznie sprawdzić
Granice stref: punkt dokładnie na granicy strefy dostawy lub promienia wyszukiwania to klasyczne źródło błędów o jeden. Zmiana współrzędnych w trakcie działania aplikacji: wiele aplikacji pyta o lokalizację raz przy starcie i nie reaguje na zmiany. Brak współrzędnych: zachowanie przy wyłączonej lokalizacji i przy odmowie uprawnienia.
Osobno — celowo nieprawidłowe dane: punkt na środku oceanu, współrzędne na drugiej półkuli, miejsca bez adresu. W żadnym z tych przypadków aplikacja nie powinna się wysypać.
Prawdziwe urządzenie a emulator
Emulator Android Studio potrafi ustawiać współrzędne i odtwarzać trasy, a na wczesnym etapie programowania to wystarcza. Ale nie odtwarza tego, co psuje się najczęściej: zachowania konkretnego systemu przy zamykaniu usług w tle, pracy przy słabym sygnale, realnych opóźnień w uzyskaniu odczytu i różnic w politykach oszczędzania energii producentów.
Dlatego scenariusz, który przeszedł na emulatorze, warto sprawdzić ponownie na prawdziwym urządzeniu — zwłaszcza jeśli testowana aplikacja korzysta z lokalizacji w tle.
Flaga pozorowanego źródła w testach
Android oznacza współrzędne od testowego dostawcy flagą. Dla QA to nie przeszkoda, tylko osobny obiekt testów: jeśli testowana aplikacja musi odrzucać pozorowane współrzędne, symulacja jest właśnie sposobem, by upewnić się, że kontrola naprawdę działa, a nie jest tylko napisana.
Jeśli aplikacja ma przyjmować dowolne współrzędne z systemu, upewnij się, że nie odrzuca ich przypadkiem z powodu tej flagi.
Testowanie aplikacji z lokalizacją w tle
W aplikacjach śledzących ruch w tle ważne są długie testy: włącz symulację, zminimalizuj aplikację i zostaw urządzenie na kilka godzin. Tak wychodzą problemy niewidoczne w pięciu minutach ręcznego testowania — utracona subskrypcja aktualizacji, narastające błędy, zatrzymanie usługi przez system.
Wskaźnikiem jest stałe powiadomienie na pasku: dopóki jest, symulacja jest aktywna.