Testowanie w rozwoju mobilnym: co to jest, jakie rodzaje i jak zorganizować

Poziomy testowania: Unit, Integration, E2E

Testy jednostkowe

Testy jednostkowe są podstawą testowania aplikacji mobilnych. Weryfikują najmniejszą jednostkę kodu — pojedynczą funkcję, metodę lub klasę w izolacji od reszty systemu. W rozwoju mobilnym testy jednostkowe są pisane w JUnit (Android) i XCTest (iOS). Dobry test jednostkowy musi być szybki, niezależny i powtarzalny — nie powinien zależeć od sieci, bazy danych ani komponentów UI. Do izolacji używa się test doubles: mocków, stubów i fake'ów.

Mockito (Java/Kotlin) i MockK (Kotlin-first) to popularne biblioteki do tworzenia obiektów mock na Androidzie. Na iOS używa się OCMock, Cuckoo lub ręcznych protokołów. Zasada: testy jednostkowe powinny pokrywać logikę biznesową i modele danych. Testy UI nie powinny powielać testów jednostkowych — weryfikują interakcję użytkownika z interfejsem.

Testy integracyjne

Testy integracyjne weryfikują interakcję między komponentami: repozytorium z bazą danych, ViewModel z serwisem API, nawigację między ekranami. W przeciwieństwie do testów jednostkowych, testy integracyjne używają rzeczywistych lub zbliżonych do rzeczywistych zależności (np. baza danych w pamięci lub serwer mock). Robolectric to framework do uruchamiania testów Android na JVM bez emulatora, przyspieszający testy integracyjne 10-krotnie.

Testy snapshot (Golden Tests) to szczególny rodzaj testów integracyjnych, które porównują wyrenderowany komponent UI z obrazem referencyjnym (snapshot). Jeśli wygląd się zmieni, test upada — programista widzi, co się zmieniło. Facebook SnapshotTestCase (iOS) i Shot (Android) to popularne narzędzia do testów snapshot.

Testy E2E i UI

Testy E2E (end-to-end) weryfikują pełny scenariusz użytkownika od początku do końca: uruchomienie aplikacji, logowanie, wykonanie akcji, sprawdzenie wyniku. Testy UI to podzbiór E2E skoncentrowany na interfejsie. Narzędzia: Espresso (Android), XCUITest (iOS), Detox (React Native). Testy E2E są najwolniejsze, dlatego uruchamia się je oddzielnie na CI — zazwyczaj w nocnych kompilacjach.

Narzędzia iOS: XCTest i XCUITest

XCTest

XCTest to wbudowany framework Apple do testów jednostkowych aplikacji mobilnych. XCTestRunner uruchamia testy na symulatorze lub prawdziwym urządzeniu. Testy dziedziczą z XCTestCase, zawierają setUp i tearDown do przygotowania i czyszczenia. XCTest zawiera XCTAssert do asercji (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) i XCTWaiter do oczekiwania na operacje asynchroniczne.

Przykład prostego testu XCTest: utworzenie modelu User, sprawdzenie poprawności inicjalizacji, formatowania nazwy i obliczania wieku. Code Coverage w Xcode pokazuje, które linie kodu są pokryte testami — cel dla projektów komercyjnych: co najmniej 70–80% pokrycia logiki biznesowej. XCTest jest zintegrowany z Xcode Server i systemami CI przez xcodebuild test.

XCUITest

XCUITest to framework Apple do testów UI. Działa poprzez identyfikatory dostępności: XCUIElementQuery znajduje przyciski, pola wprowadzania, tabele według etykiety, identyfikatora lub typu. XCUITest rejestruje sekwencję działań (record/playback) i generuje kod testu. Ważne: wszystkie elementy UI muszą mieć accessibilityIdentifier dla stabilnego działania testów.

Narzędzia Android: JUnit, Espresso, Robolectric

JUnit i Mockito

JUnit to podstawowy framework do testów jednostkowych aplikacji mobilnych w Java/Kotlin. Na Androidzie używa się JUnit 4 (ostatnia stabilna wersja 4.13.2) i JUnit 5 dla nowych projektów. Mockito to biblioteka do tworzenia obiektów mock: when(mock.method()).thenReturn(value) — standardowy wzorzec izolacji testowanej klasy od zależności.

Przykład testu JUnit dla Androida:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.*;
import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)
public class LoginViewModelTest {

    @Mock
    AuthRepository authRepository;

    @Test
    public void login_emptyEmail_returnsError() {
        LoginViewModel vm = new LoginViewModel(authRepository);
        String result = vm.login("", "password123");
        assertEquals("Email cannot be empty", result);
        verify(authRepository, never()).authenticate(any());
    }
}

Espresso i UI Automator

Espresso to framework Google do testów UI Androida. Espresso automatycznie synchronizuje się z wątkiem UI: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso jest łatwy w pisaniu i stabilny dzięki wbudowanemu oczekiwaniu na stan bezczynności. UI Automator to framework do testów międzyaplikacyjnych, który może wchodzić w interakcje z elementami systemu (okna dialogowe uprawnień, panel powiadomień).

Narzędzia wieloplatformowe: Detox, Appium

Detox dla React Native

Detox to szaroskrzynkowy framework E2E do testowania aplikacji mobilnych React Native od Wix. Detox działa na obu platformach z jednej bazy kodu testów, używając wewnętrznie Espresso (Android) i XCUITest (iOS). Detox automatycznie czeka, aż aplikacja stanie się bezczynna (brak animacji, żądań sieciowych, timerów), a dopiero potem wykonuje następną akcję.

Appium

Appium to uniwersalny framework wieloplatformowy obsługujący Android, iOS, Web i aplikacje hybrydowe. Appium używa protokołu WebDriver i obsługuje dowolny język programowania (Java, Python, JS, Ruby). Appium Server działa jako serwer HTTP, który tłumaczy polecenia na natywne polecenia UI Automator / XCUITest. Główną wadą Appium jest szybkość: testy działają wolniej niż natywne Espresso czy XCUITest.

TDD i BDD: metodologie testowania

TDD: Test-Driven Development

TDD to metodologia testowania aplikacji mobilnych, w której test jest pisany przed kodem implementacji. Cykl Red-Green-Refactor: (1) napisz test, który nie przechodzi (Red), (2) napisz minimalny kod, aby test przeszedł (Green), (3) refaktoryzuj kod, zachowując przejście testu. TDD zapewnia 100% pokrycia testami nowej funkcjonalności i czystą architekturę, ponieważ test jest pierwszą specyfikacją wymagania.

BDD: Behaviour-Driven Development

BDD to rozszerzenie TDD, w którym testy są pisane w języku naturalnym w formacie Given-When-Then. Given (kontekst) — When (akcja) — Then (oczekiwany wynik). Testy BDD są zrozumiałe dla wszystkich członków zespołu: programistów, testerów, analityków i klientów. Mock vs Stub vs Fake: Mock weryfikuje interakcję (czy metoda została wywołana), Stub zwraca stałe dane, Fake to uproszczona działająca implementacja (np. baza danych w pamięci). W IT Sectr używamy TDD dla krytycznej logiki biznesowej i BDD dla scenariuszy akceptacyjnych.

Test Doubles to ogólna nazwa obiektów zastępujących rzeczywiste zależności w testach. Istnieją cztery typy: Dummy (obiekt do wypełnienia parametrów, nieużywany), Stub (zwraca zadane wartości), Spy (rejestruje wywołania do weryfikacji), Mock (predefiniuje oczekiwane wywołania). Zrozumienie różnicy jest kluczowe dla prawidłowego projektowania testów.

CI/CD i Device Farm

Automatyzacja testów w CI/CD

CI/CD — Continuous Integration i Continuous Delivery: praktyka automatycznego budowania i testowania aplikacji mobilnych przy każdej zmianie kodu. W rozwoju mobilnym pipeline CI/CD obejmuje: linting, testy jednostkowe, testy integracyjne, budowanie APK/IPA i testy UI. GitHub Actions i Bitrise to popularne platformy do mobilnego CI/CD. Testy powinny działać szybko: testy jednostkowe w 1–2 minuty, integracyjne w 5–10, UI w 15–30 minut.

Device Farm

Device Farm to farma rzeczywistych urządzeń do testowania. Firebase Test Lab (Android) i Xcode Cloud (iOS) zapewniają dostęp w chmurze do setek modeli urządzeń. Device Farm ujawnia problemy niewidoczne na emulatorach: różne rozmiary ekranów, wydajność na starszych urządzeniach, problemy ze zgodnością. W IT Sectr regularnie używamy Firebase Test Lab dla Androida i Xcode Cloud dla iOS.