Testning i mobilutveckling: vad det är, vilka typer och hur man organiserar

Testnivåer: Unit, Integration, E2E

Enhetstestning

Enhetstester är grunden för mobilappstestning. De verifierar den minsta enheten av kod — en enskild funktion, metod eller klass isolerad från resten av systemet. I mobilutveckling skrivs enhetstester i JUnit (Android) och XCTest (iOS). Ett bra enhetstest måste vara snabbt, oberoende och repeterbart — det bör inte bero på nätverk, databas eller UI-komponenter. För isolering används testdoubles: mockar, stubbar och fejk.

Mockito (Java/Kotlin) och MockK (Kotlin-first) är populära bibliotek för att skapa mock-objekt på Android. På iOS används OCMock, Cuckoo eller manuella protokoll. Regel: enhetstester bör täcka affärslogik och datamodeller. UI-tester bör inte duplicera enhetstester — de verifierar användarens interaktion med gränssnittet.

Integrationstestning

Integrationstester verifierar interaktion mellan komponenter: databas med repository, ViewModel med API-tjänst, navigering mellan skärmar. Till skillnad från enhetstester använder integrationstester verkliga eller nära verkliga beroenden (t.ex. minnesdatabas eller mock-server). Robolectric är ett ramverk för att köra Android-tester på JVM utan emulator, vilket snabbar upp integrationstester 10 gånger.

Ögonblicksbildstester (Golden Tests) är en speciell typ av integrationstest som jämför en renderad UI-komponent med en referensbild (ögonblicksbild). Om utseendet ändras misslyckas testet — utvecklaren ser vad som ändrats. Facebook SnapshotTestCase (iOS) och Shot (Android) är populära verktyg för ögonblicksbildstestning.

E2E- och UI-testning

E2E-tester (end-to-end) verifierar hela användarscenariot från början till slut: appstart, inloggning, utförande av en åtgärd, kontroll av resultatet. UI-tester är en delmängd av E2E med fokus på gränssnittet. Verktyg: Espresso (Android), XCUITest (iOS), Detox (React Native). E2E-tester är långsammast, så de körs separat på CI — vanligtvis i nattliga byggen.

iOS-verktyg: XCTest och XCUITest

XCTest

XCTest är Apples inbyggda ramverk för enhetstestning av mobilapplikationer. XCTestRunner kör tester på simulatorn eller en verklig enhet. Tester ärver från XCTestCase, innehåller setUp och tearDown för förberedelse och rensning. XCTest innehåller XCTAssert för påståenden (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) och XCTWaiter för att vänta på asynkrona operationer.

Exempel på ett enkelt XCTest-test: skapa en User-modell, kontrollera korrektheten av initiering, namformatering och åldersberäkning. Code Coverage i Xcode visar vilka kodrader som täcks av tester — målet för kommersiella projekt: minst 70–80% täckning av affärslogik. XCTest är integrerat med Xcode Server och CI-system via xcodebuild test.

XCUITest

XCUITest är Apples ramverk för UI-testning. Det fungerar via tillgänglighetsidentifierare: XCUIElementQuery hittar knappar, inmatningsfält, tabeller efter etikett, identifierare eller typ. XCUITest spelar in en sekvens av åtgärder (record/playback) och genererar testkod. Viktigt: alla UI-element måste ha en accessibilityIdentifier för stabil testdrift.

Android-verktyg: JUnit, Espresso, Robolectric

JUnit och Mockito

JUnit är det grundläggande ramverket för modultestning av mobilapplikationer i Java/Kotlin. På Android används JUnit 4 (senaste stabila versionen 4.13.2) och JUnit 5 för nya projekt. Mockito är ett bibliotek för att skapa mock-objekt: when(mock.method()).thenReturn(value) — ett standardmönster för att isolera den testade klassen från beroenden.

Exempel på ett JUnit-test för Android:

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 och UI Automator

Espresso är Googles ramverk för Android UI-tester. Espresso synkroniseras automatiskt med UI-tråden: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso är lätt att skriva och stabilt tack vare inbyggd väntan på inaktivt tillstånd. UI Automator är ett ramverk för tester mellan applikationer som kan interagera med systemelement (behörighetsdialoger, notifieringsskugga).

Plattformsoberoende verktyg: Detox, Appium

Detox för React Native

Detox är ett grå-låda E2E-ramverk för testning av React Native-mobilapplikationer från Wix. Detox fungerar på båda plattformarna från en enda testkodbas och använder Espresso (Android) och XCUITest (iOS) under huven. Detox väntar automatiskt tills appen blir inaktiv (inga animationer, nätverksförfrågningar, timer) och utför först därefter nästa åtgärd.

Appium

Appium är ett universellt plattformsoberoende ramverk som stöder Android, iOS, Web och hybridapplikationer. Appium använder WebDriver-protokollet och stöder vilket programmeringsspråk som helst (Java, Python, JS, Ruby). Appium Server fungerar som en HTTP-server som översätter kommandon till inbyggda UI Automator / XCUITest-kommandon. Den största nackdelen med Appium är hastigheten: tester körs långsammare än inbyggda Espresso eller XCUITest.

TDD och BDD: testmetodiker

TDD: Test-Driven Development

TDD är en metodik för mobilappstestning där testet skrivs före implementeringskoden. Red-Green-Refactor-cykeln: (1) skriv ett test som misslyckas (Red), (2) skriv minimal kod för att få testet att passera (Green), (3) refaktorera koden medan testet förblir godkänt. TDD ger 100% testtäckning för ny funktionalitet och en ren arkitektur, eftersom testet är den första specifikationen av kravet.

BDD: Behaviour-Driven Development

BDD är en utvidgning av TDD där tester skrivs på naturligt språk i formatet Given-When-Then. Given (kontext) — When (åtgärd) — Then (förväntat resultat). BDD-tester är förståeliga för alla teammedlemmar: utvecklare, testare, analytiker och kunder. Mock vs Stub vs Fake: Mock verifierar interaktion (om metoden anropades), Stub returnerar fasta data, Fake är en förenklad fungerande implementering (t.ex. minnesdatabas). På IT Sectr använder vi TDD för kritisk affärslogik och BDD för acceptansscenarier.

Testdoubles är det allmänna namnet på objekt som ersätter verkliga beroenden i tester. Det finns fyra typer: Dummy (objekt för att fylla parametrar, används inte), Stub (returnerar givna värden), Spy (registrerar anrop för verifiering), Mock (fördefinierar förväntade anrop). Att förstå skillnaden är avgörande för korrekt testdesign.

CI/CD och Device Farm

Testautomatisering i CI/CD

CI/CD — Kontinuerlig Integration och Kontinuerlig Leverans: praxis att automatiskt bygga och testa mobilapplikationer vid varje kodändring. I mobilutveckling inkluderar CI/CD-pipelinen: linting, enhetstester, integrationstester, APK/IPA-bygge och UI-tester. GitHub Actions och Bitrise är populära plattformar för mobil CI/CD. Tester bör köras snabbt: enhetstester på 1–2 minuter, integrationstester på 5–10, UI-tester på 15–30 minuter.

Device Farm

Device Farm är en farm av verkliga enheter för testning. Firebase Test Lab (Android) och Xcode Cloud (iOS) ger molnåtkomst till hundratals enhetsmodeller. Device Farm avslöjar problem som inte är synliga på emulatorer: olika skärmstorlekar, prestanda på äldre enheter, kompatibilitetsproblem. På IT Sectr använder vi regelbundet Firebase Test Lab för Android och Xcode Cloud för iOS.