Na tej stronie znajdziesz podstawowe zasady testowania aplikacji na Androida, w tym najważniejsze sprawdzone metody i ich zalety.
Korzyści z testowania
Testowanie jest nieodłączną częścią procesu tworzenia aplikacji. Regularne przeprowadzanie testów aplikacji umożliwia weryfikowanie poprawności jej działania, funkcjonalności i łatwości obsługi jeszcze przed opublikowaniem.
Możesz ręcznie przetestować aplikację, poruszając się po niej. Możesz używać różnych urządzeń i emulatorów, zmieniać język systemu oraz próbować wygenerować każdy błąd użytkownika lub przejść każdy proces użytkownika.
Testowanie ręczne jest jednak mało skalowalne i łatwo w nim przeoczyć regresje w działaniu aplikacji. Testy automatyczne polegają na używaniu narzędzi, które przeprowadzają testy za Ciebie. Jest to szybsze, bardziej powtarzalne i zwykle daje więcej przydatnych opinii o aplikacji na wcześniejszym etapie procesu programowania.
Rodzaje testów na Androidzie
Aplikacje mobilne są złożone i muszą dobrze działać w wielu środowiskach. Dlatego istnieje wiele rodzajów testów.
Temat
W zależności od tematu istnieją różne rodzaje testów:
- Testy funkcjonalne: czy aplikacja działa zgodnie z założeniami?
- Testy wydajności: czy działa szybko i wydajnie?
- Testowanie ułatwień dostępu: czy działa dobrze z usługami ułatwień dostępu?
- Testowanie zgodności: czy działa dobrze na każdym urządzeniu i na każdym poziomie interfejsu API?
Zakres
Testy różnią się też rozmiarem lub stopniem izolacji:
- Testy jednostkowe lub małe testy weryfikują tylko bardzo małą część aplikacji, np. metodę lub klasę.
- Testy end-to-end lub duże testy weryfikują jednocześnie większe części aplikacji, np. cały ekran lub ścieżkę użytkownika.
- Testy średnie sprawdzają integrację między co najmniej 2 jednostkami.
Testy można klasyfikować na wiele sposobów. Najważniejsza różnica dla deweloperów aplikacji dotyczy jednak miejsca, w którym są przeprowadzane testy.
Testy z instrumentacją a testy lokalne
Testy możesz przeprowadzić na urządzeniu z Androidem lub na innym komputerze:
- Testy z instrumentacją są przeprowadzane na urządzeniu z Androidem – fizycznym lub emulowanym. Aplikacja jest tworzona i instalowana razem z aplikacją testową, która wstrzykuje polecenia i odczytuje stan. Testy instrumentowane to zwykle testy interfejsu, które uruchamiają aplikację, a następnie wchodzą z nią w interakcję.
- Testy lokalne są przeprowadzane na komputerze deweloperskim lub serwerze, dlatego są też nazywane testami po stronie hosta. Są one zwykle małe i szybkie, a ich celem jest odizolowanie testowanego elementu od reszty aplikacji.
Nie wszystkie testy jednostkowe są lokalne, a nie wszystkie testy kompleksowe są przeprowadzane na urządzeniu. Przykład:
- Duży test lokalny: możesz użyć lokalnego symulatora Androida, np. Robolectric.
- Mały test z instrumentacją: możesz sprawdzić, czy Twój kod dobrze współpracuje z funkcją platformy, np. bazą danych SQLite. Ten test możesz przeprowadzić na kilku urządzeniach, aby sprawdzić integrację z różnymi wersjami SQLite.
Przykłady
Poniższe fragmenty kodu pokazują, jak wchodzić w interakcję z interfejsem w testach interfejsu z instrumentacją, które klikają element i sprawdzają, czy wyświetla się inny element.
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Interfejs tworzenia
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
Ten fragment kodu pokazuje część testu jednostkowego dla ViewModelu (lokalny test po stronie hosta):
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
Architektura umożliwiająca testowanie
W przypadku architektury aplikacji umożliwiającej testowanie kod ma strukturę, która pozwala łatwo testować różne jego części w izolacji. Architektury, które można testować, mają też inne zalety, takie jak lepsza czytelność, łatwość konserwacji, skalowalność i możliwość ponownego wykorzystania.
Architektura, której nie można przetestować, daje te wyniki:
- Większe, wolniejsze i bardziej niestabilne testy. Klasy, których nie można przetestować jednostkowo, mogą wymagać większych testów integracyjnych lub testów interfejsu.
- Mniej możliwości testowania różnych scenariuszy. Większe testy działają wolniej, więc testowanie wszystkich możliwych stanów aplikacji może być nierealne.
Więcej informacji o wytycznych dotyczących architektury znajdziesz w przewodniku po architekturze aplikacji.
Podejścia do rozdzielania
Jeśli możesz wyodrębnić część funkcji, klasy lub modułu z reszty, testowanie jej jest łatwiejsze i skuteczniejsze. Ta praktyka jest znana jako rozdzielanie i jest najważniejszą koncepcją w architekturze testowalnej.
Do typowych technik rozdzielania należą:
- Podziel aplikację na warstwy, takie jak warstwa prezentacji, domeny i danych. Aplikację możesz też podzielić na moduły, po jednym na każdą funkcję.
- Unikaj dodawania logiki do encji, które mają wiele zależności, takich jak działania i fragmenty. Używaj tych klas jako punktów wejścia do frameworka i przenoś interfejs i logikę biznesową w inne miejsca, np. do funkcji kompozycyjnej, ViewModelu lub warstwy domeny.
- Unikaj bezpośrednich zależności od platformy w klasach zawierających logikę biznesową. Na przykład nie używaj kontekstów Androida w klasach ViewModel.
- Ułatw zastępowanie zależności. Na przykład używaj interfejsów zamiast konkretnych implementacji. Używaj wstrzykiwania zależności, nawet jeśli nie korzystasz z platformy DI.
Dalsze kroki
Teraz, gdy wiesz już, dlaczego warto przeprowadzać testy i jakie są ich 2 główne rodzaje, możesz przeczytać artykuł Co testować lub dowiedzieć się więcej o strategiach testowania.
Jeśli chcesz utworzyć pierwszy test i uczyć się przez działanie, zapoznaj się z samouczkami dotyczącymi testowania.