Testen in mobiele ontwikkeling: wat het is, welke soorten en hoe te organiseren

Testniveaus: Unit, Integratie, E2E

Unittesten

Unittesten zijn de basis van mobiele app-testen. Ze verifiëren de kleinste eenheid code — een enkele functie, methode of klasse geïsoleerd van de rest van het systeem. In mobiele ontwikkeling worden unittesten geschreven in JUnit (Android) en XCTest (iOS). Een goede unittest moet snel, onafhankelijk en herhaalbaar zijn — het mag niet afhankelijk zijn van netwerk, database of UI-componenten. Voor isolatie worden test doubles gebruikt: mocks, stubs en fakes.

Mockito (Java/Kotlin) en MockK (Kotlin-first) zijn populaire bibliotheken voor het maken van mock-objecten op Android. Op iOS worden OCMock, Cuckoo of handmatige protocollen gebruikt. Regel: unittesten moeten bedrijfslogica en gegevensmodellen dekken. UI-tests mogen unittesten niet dupliceren — ze verifiëren gebruikersinteractie met de interface.

Integratietesten

Integratietests verifiëren interactie tussen componenten: repository met database, ViewModel met API-service, navigatie tussen schermen. In tegenstelling tot unittesten gebruiken integratietests echte of bijna-echte afhankelijkheden (bijv. in-memory database of mock-server). Robolectric is een framework voor het uitvoeren van Android-tests op JVM zonder emulator, wat integratietests 10x versnelt.

Snapshot-tests (Golden Tests) zijn een speciaal type integratietest die een gerenderde UI-component vergelijken met een referentieafbeelding (snapshot). Als het uiterlijk verandert, faalt de test — de ontwikkelaar ziet wat er veranderd is. Facebook SnapshotTestCase (iOS) en Shot (Android) zijn populaire tools voor snapshot-testen.

E2E- en UI-testen

E2E-tests (end-to-end) verifiëren het volledige gebruikersscenario van begin tot eind: app starten, inloggen, een actie uitvoeren, resultaat controleren. UI-tests zijn een subset van E2E gericht op de interface. Tools: Espresso (Android), XCUITest (iOS), Detox (React Native). E2E-tests zijn het langzaamst, dus worden ze apart uitgevoerd op CI — meestal in nachtelijke builds.

iOS Tools: XCTest en XCUITest

XCTest

XCTest is het ingebouwde framework van Apple voor unittesten van mobiele applicaties. XCTestRunner voert tests uit op de simulator of een echt apparaat. Tests erven van XCTestCase, bevatten setUp en tearDown voor voorbereiding en opschoning. XCTest bevat XCTAssert voor beweringen (XCTAssertEqual, XCTAssertNil, XCTAssertTrue) en XCTWaiter voor het wachten op asynchrone bewerkingen.

Voorbeeld van een eenvoudige XCTest-test: een User-model maken, de juistheid van initialisatie, naamopmaak en leeftijdsberekening controleren. Code Coverage in Xcode laat zien welke coderegels door tests worden gedekt — het doel voor commerciële projecten: minimaal 70–80% dekking van bedrijfslogica. XCTest is geïntegreerd met Xcode Server en CI-systemen via xcodebuild test.

XCUITest

XCUITest is het framework van Apple voor UI-testen. Het werkt via toegankelijkheidsidentificatoren: XCUIElementQuery vindt knoppen, invoervelden, tabellen op label, identifier of type. XCUITest neemt een reeks acties op (record/playback) en genereert testcode. Belangrijk: alle UI-elementen moeten een accessibilityIdentifier hebben voor stabiele werking van tests.

Android Tools: JUnit, Espresso, Robolectric

JUnit en Mockito

JUnit is het basisframework voor unittesten van mobiele applicaties in Java/Kotlin. Op Android worden JUnit 4 (laatste stabiele versie 4.13.2) en JUnit 5 voor nieuwe projecten gebruikt. Mockito is een bibliotheek voor het maken van mock-objecten: when(mock.method()).thenReturn(value) — een standaard patroon voor het isoleren van de geteste klasse van afhankelijkheden.

Voorbeeld van een JUnit-test voor 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 en UI Automator

Espresso is het framework van Google voor Android UI-tests. Espresso synchroniseert automatisch met de UI-thread: onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed())). Espresso is gemakkelijk te schrijven en stabiel dankzij ingebouwde inactieve toestand wachttijd. UI Automator is een framework voor cross-applicatie tests die kunnen interageren met systeemelementen (machtigingsdialogen, notificatiescherm).

Cross-platform Tools: Detox, Appium

Detox voor React Native

Detox is een grijze-box E2E-framework voor het testen van React Native mobiele applicaties van Wix. Detox werkt op beide platforms vanaf een enkele testcodebase, met Espresso (Android) en XCUITest (iOS) onder de motorkap. Detox wacht automatisch tot de app inactief wordt (geen animaties, netwerkverzoeken, timers) en voert pas daarna de volgende actie uit.

Appium

Appium is een universeel cross-platform framework dat Android, iOS, Web en hybride applicaties ondersteunt. Appium gebruikt het WebDriver-protocol en ondersteunt elke programmeertaal (Java, Python, JS, Ruby). Appium Server werkt als een HTTP-server die opdrachten vertaalt naar native UI Automator / XCUITest-opdrachten. Het grootste nadeel van Appium is snelheid: tests werken langzamer dan native Espresso of XCUITest.

TDD en BDD: testmethodologieën

TDD: Test-Driven Development

TDD is een mobiele app-testmethodologie waarbij de test wordt geschreven vóór de implementatiecode. De Red-Green-Refactor-cyclus: (1) schrijf een test die faalt (Red), (2) schrijf minimale code om de test te laten slagen (Green), (3) refactor de code terwijl de test blijft slagen. TDD geeft 100% testdekking voor nieuwe functionaliteit en een schone architectuur, omdat de test de eerste specificatie van de vereiste is.

BDD: Behaviour-Driven Development

BDD is een uitbreiding van TDD waarbij tests in natuurlijke taal worden geschreven in Given-When-Then-formaat. Given (context) — When (actie) — Then (verwacht resultaat). BDD-tests zijn begrijpelijk voor alle teamleden: ontwikkelaars, testers, analisten en klanten. Mock vs Stub vs Fake: Mock verifieert interactie (of de methode is aangeroepen), Stub retourneert vaste gegevens, Fake is een vereenvoudigde werkende implementatie (bijv. in-memory DB). Bij IT Sectr gebruiken we TDD voor kritieke bedrijfslogica en BDD voor acceptatiescenario's.

Test Doubles is de algemene naam voor objecten die echte afhankelijkheden in tests vervangen. Er zijn vier typen: Dummy (object om parameters te vullen, niet gebruikt), Stub (retourneert gegeven waarden), Spy (registreert aanroepen voor verificatie), Mock (definieert verwachte aanroepen vooraf). Het begrijpen van het verschil is cruciaal voor een goed testontwerp.

CI/CD en Device Farm

Testautomatisering in CI/CD

CI/CD — Continue Integratie en Continue Levering: de praktijk van het automatisch bouwen en testen van mobiele applicaties bij elke codewijziging. In mobiele ontwikkeling omvat de CI/CD-pijplijn: linting, unittesten, integratietests, APK/IPA-build en UI-tests. GitHub Actions en Bitrise zijn populaire platforms voor mobiele CI/CD. Tests moeten snel worden uitgevoerd: unittesten in 1–2 minuten, integratietests in 5–10, UI-tests in 15–30 minuten.

Device Farm

Device Farm is een boerderij van echte apparaten voor testen. Firebase Test Lab (Android) en Xcode Cloud (iOS) bieden cloudtoegang tot honderden apparaatmodellen. Device Farm onthult problemen die niet zichtbaar zijn op emulators: verschillende schermformaten, prestaties op oudere apparaten, compatibiliteitsproblemen. Bij IT Sectr gebruiken we regelmatig Firebase Test Lab voor Android en Xcode Cloud voor iOS.