React Native Academy · Les

Gebruikersreizen met meerdere schermen testen

Schrijf een Maestro-flow voor aanmelden, onboarding en het gebruik van kernfuncties op meerdere schermen, waarbij u inputText en tapOn gebruikt om elke stap uit te voeren.

Les 3 van 413 stappen

Gebruikersreizen met meerdere schermen testen is een gratis React Native Academy-les op CoddyKit. Dit is les 3 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject React Native Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus React Native Academy bevat in totaal 4 lessen.

Wat is een gebruikersreis over meerdere schermen?

Een gebruikersreis is een reeks interacties die meerdere schermen omvat om een zinvol doel te bereiken. Voorbeelden zijn de registratiereis (onboarding → e-mailregistratie → profiel instellen → startscherm), de aankoopreis (bladeren → aan winkelwagen toevoegen → afrekenen → bevestiging) en de reis voor het maken van content (startscherm → opstellen → voorbeeld bekijken → plaatsen).

E2E-tests die complete gebruikersreizen afdekken leveren de meeste waarde, omdat ze controleren of alle onderdelen van je app correct samenwerken. Een unit-test kan bevestigen dat een formulier correct valideert, maar alleen een test van de gebruikersreis bevestigt dat een gevalideerd formulier daadwerkelijk naar het volgende scherm navigeert.

Een flow voor een gebruikersreis plannen

Schets de gebruikersreis op papier voordat je de YAML schrijft: welke schermen verschijnen, waarop de gebruiker op elk scherm tikt of wat die invoert en wat de verwachte eindstatus is. Bepaal eerst het standaardpad — de normale flow zonder fouten — en voeg daarna flows voor randgevallen met foutstatussen toe.

Verdeel de gebruikersreis in logische fasen en geef je YAML dienovereenkomstig commentaar. Comments in YAML beginnen met #. Duidelijke comments maken de flow leesbaar voor teamleden die deze niet hebben geschreven en helpen je te achterhalen welke fase is mislukt wanneer de test een fout meldt.

# Journey: User Registration and First Login
# Phase 1: Onboarding
# Phase 2: Sign Up Form
# Phase 3: Email Verification (mocked in dev build)
# Phase 4: Profile Setup
# Phase 5: Home Screen Verification

appId: com.example.myapp
---
# Phase 1: Onboarding
- launchApp:
    clearState: true
- assertVisible:
    text: 'Welcome'
- tapOn:
    text: 'Create Account'

De flow voor de registratiereis

De registratiereis doorloopt het registratieformulier, valideert het bevestigingsscherm en controleert of de gebruiker op het startscherm terechtkomt. Gebruik de sectie env om testgegevens parametriseerbaar te maken, zodat je dezelfde flow met verschillende gebruikers kunt uitvoeren door alleen de omgevingsvariabelen te wijzigen.

Elke fase eindigt met een assertVisible om te bevestigen dat de overgang is geslaagd voordat de volgende fase begint. Zo krijg je een nauwkeurige foutlocatie in het testrapport — je weet precies welke schermovergang is mislukt.

appId: com.example.myapp
env:
  TEST_EMAIL: testuser@example.com
  TEST_PASSWORD: TestPass123!
  TEST_NAME: Test User
---
# Phase 1: Open sign-up form
- launchApp:
    clearState: true
- tapOn:
    text: 'Create Account'
- assertVisible:
    text: 'Create your account'

# Phase 2: Fill in the form
- tapOn:
    id: 'name-input'
- inputText: '${TEST_NAME}'
- tapOn:
    id: 'email-input'
- inputText: '${TEST_EMAIL}'
- tapOn:
    id: 'password-input'
- inputText: '${TEST_PASSWORD}'
- tapOn:
    text: 'Sign Up'

# Phase 3: Verify success screen
- assertVisible:
    text: 'Account Created'
    timeout: 8000

De gebruikersreis voor inloggen en content bekijken

Een veelvoorkomende gebruikersreis is: inloggen, een lijst bekijken, een item openen, ermee werken en teruggaan. Hiermee test je voorwaartse en achterwaartse navigatie, het laden van gegevens op elk scherm en de interactie op het detailscherm.

Gebruik de opdracht back om op Android het indrukken van de terugknop van het apparaat te simuleren. Veeg op iOS terug of tik op de terugknop met tapOn: text: 'Back'. Test beide navigatierichtingen om fouten op te sporen waarbij de app na teruggaan in een defecte toestand achterblijft.

appId: com.example.myapp
---
- launchApp
- runFlow: subflows/login.yaml

# Browse the feed
- assertVisible:
    text: 'Latest Posts'
    timeout: 8000
- scroll:
    direction: DOWN

# Open a post
- tapOn:
    text: 'Top 10 React Native Tips'
- waitForAnimationToEnd
- assertVisible:
    text: 'Top 10 React Native Tips'

# Like the post
- tapOn:
    id: 'like-button'
- assertVisible:
    id: 'liked-indicator'

# Go back
- back
- assertVisible:
    text: 'Latest Posts'

Tabnavigatie testen

Bij apps met navigatie via tabs onderaan moet je testen of elke tab het juiste scherm opent. Test de eerste tab, schakel naar elke andere tab, controleer of de content wordt geladen en schakel terug. Zo spoor je koppelingsfouten op waarbij tabs naar het verkeerde scherm navigeren.

Gebruik tapOn met de tekst van het tablabel of met de id van de knop in de tabblak. Controleer na het wisselen van tab altijd unieke content die bevestigt dat de juiste tab actief is.

# Test all three tabs of the main navigator
- launchApp
- runFlow: subflows/login.yaml

# Tab 1: Home (default)
- assertVisible:
    text: 'Your Feed'

# Tab 2: Search
- tapOn:
    id: 'tab-search'
- waitForAnimationToEnd
- assertVisible:
    id: 'search-input'

# Tab 3: Profile
- tapOn:
    id: 'tab-profile'
- waitForAnimationToEnd
- assertVisible:
    text: 'My Profile'

# Return to Tab 1
- tapOn:
    id: 'tab-home'
- assertVisible:
    text: 'Your Feed'

Foutpaden in formulieren testen

Tests van gebruikersreizen moeten zowel het standaardpad als het foutpad afdekken. Een aparte flow voor het foutpad controleert of validatiefouten correct verschijnen, de gebruiker deze kan herstellen en het formulier na de correctie succesvol wordt verzonden.

Zo spoor je fouten op zoals: foutmeldingen die niet verschijnen, een formulier dat na een mislukte verzending niet opnieuw wordt ingeschakeld of validatie die niet opnieuw wordt uitgevoerd nadat de gebruiker invoer heeft gecorrigeerd. Deze fouten zijn zonder een E2E-test moeilijk te vinden, omdat er meerdere interactieve stappen nodig zijn om ze te reproduceren.

# Error path: submit empty form, fix errors, succeed
appId: com.example.myapp
---
- launchApp
- tapOn:
    text: 'Sign In'

# Submit without filling in fields
- tapOn:
    text: 'Submit'
- assertVisible:
    text: 'Email is required'
- assertVisible:
    text: 'Password is required'

# Fill in email only
- tapOn:
    id: 'email-input'
- inputText: 'user@example.com'
- tapOn:
    text: 'Submit'
- assertNotVisible:
    text: 'Email is required'
- assertVisible:
    text: 'Password is required'

# Complete the form
- tapOn:
    id: 'password-input'
- inputText: 'correctpassword'
- tapOn:
    text: 'Submit'
- assertVisible:
    text: 'Home'
    timeout: 8000

Modale vensters in gebruikersreizen verwerken

Modale vensters en onderste bladen blokkeren interactie met het onderliggende scherm. Test of modale vensters correct verschijnen, de verwachte content bevatten en goed worden gesloten. Controleer na het sluiten van een modaal venster of het onderliggende scherm nog steeds de juiste status heeft.

Test bij bevestigingsdialoogvensters (zoals een bevestiging voor verwijderen) beide paden: tikken op Confirm om de actie te voltooien en tikken op Cancel om deze af te breken. Het pad voor Cancel wordt vaak niet getest en bevat daarom vaak fouten.

# Test delete with confirmation dialog
- tapOn:
    id: 'delete-button'

# Confirm dialog appears
- assertVisible:
    text: 'Delete Post?'
- assertVisible:
    text: 'This action cannot be undone'

# Cancel path: dismiss dialog
- tapOn:
    text: 'Cancel'
- assertNotVisible:
    text: 'Delete Post?'
- assertVisible:
    text: 'My Post Title'  # Post still exists

# Now actually delete
- tapOn:
    id: 'delete-button'
- tapOn:
    text: 'Delete'
- assertNotVisible:
    text: 'My Post Title'  # Post is gone
    timeout: 5000

Omgevingsvariabelen voor testgegevens gebruiken

Testgegevens rechtstreeks in flows opnemen maakt deze kwetsbaar wanneer het testaccount verandert of de app bij elke uitvoering unieke gegevens vereist. Gebruik de sectie env bovenaan het flowbestand om variabelen te definiëren en geef ze door op de opdrachtregel om ze tijdens runtime te overschrijven.

Je kunt ook omgevingsvariabelen vanuit CI-systemen doorgeven met argumenten op de opdrachtregel. Zo kun je voor verschillende omgevingen verschillende testaccounts of API-eindpunten gebruiken zonder de YAML-bestanden te wijzigen.

# Define defaults in the flow file
env:
  BASE_URL: https://api.dev.example.com
  TEST_EMAIL: ci_test@example.com
  TEST_PASSWORD: CI_Password_2024

# Override at runtime from the command line:
maestro test \
  -e TEST_EMAIL=prod_test@example.com \
  -e TEST_PASSWORD=ProdPass123 \
  maestro/flows/login.yaml

# In CI (GitHub Actions):
# - name: Run Maestro tests
#   env:
#     TEST_EMAIL: ${{ secrets.TEST_EMAIL }}
#   run: maestro test -e TEST_EMAIL=$TEST_EMAIL maestro/flows/

Deep links in gebruikersreizen testen

Deep links openen je app rechtstreeks op een specifiek scherm. Test deze in Maestro door de opdracht openLink te gebruiken om de URL van de deep link te activeren en vervolgens te controleren of de app het juiste scherm heeft geopend.

Tests van deep links controleren of je app inkomende URL's correct verwerkt en naar de juiste plek navigeert. Ze bevestigen ook dat het scherm correct wordt weergegeven wanneer er rechtstreeks naartoe wordt genavigeerd, zonder de normale navigatieflow te doorlopen.

# Test deep link opens the correct post
- launchApp
- runFlow: subflows/login.yaml

# Open a deep link to a specific post
- openLink: 'myapp://posts/post-id-123'
- waitForAnimationToEnd

# Assert we are on the correct post detail screen
- assertVisible:
    text: 'Deep Link Post Title'
    timeout: 8000

# Verify back navigation works after deep link
- back
- assertVisible:
    text: 'Home'

Flows per functie organiseren

Organiseer flows in mappen per functie in plaats van per scherm naarmate je testsuite groeit. Zo kun je eenvoudig alle tests voor een specifieke functie uitvoeren en de relevante test vinden wanneer een functie niet meer werkt.

Een aanbevolen mappenstructuur: maestro/flows/auth/ voor authenticatieflows, maestro/flows/feed/ voor feedfuncties, maestro/flows/profile/ voor profielfuncties en maestro/flows/subflows/ voor gedeelde stappen. Voer een specifieke functie uit met maestro test maestro/flows/auth/.

maestro/
  flows/
    auth/
      registration.yaml
      login.yaml
      password-reset.yaml
      logout.yaml
    feed/
      browse.yaml
      like-post.yaml
      create-post.yaml
    profile/
      view-profile.yaml
      edit-profile.yaml
    subflows/
      login.yaml
      logout.yaml
      dismiss-permission-dialog.yaml

Tests van gebruikersreizen op lange termijn onderhouden

E2E-tests zijn de duurste tests om te onderhouden, omdat wijzigingen in de UI ze breken, zelfs wanneer de logica correct is. Beperk het onderhoud door te zoeken op semantische content (tekst die de gebruiker ziet) in plaats van op implementatiedetails (component-ID's), flows te richten op kritieke paden en herbruikbare stappen uit te splitsen in subflows.

Wanneer een flow na een nieuw UI-ontwerp niet meer werkt, werk je de query in tapOn of assertVisible bij zodat deze overeenkomt met de nieuwe tekst of ID. De testlogica zelf verandert vaak niet — alleen de selector. Dat is een functie en geen fout: de test heeft opgemerkt dat de UI op een manier is gewijzigd die de gebruiker ziet.

Korte controle

Test je begrip van de concepten voor mobiele ontwikkeling met React Native uit deze les.

Beantwoord dit in de interactieve les

Samenvatting van de les

In deze les heb je geleerd: hoe je flows voor gebruikersreizen over meerdere schermen plant en schrijft waarmee je complete functies van begin tot eind test, hoe je zowel standaardpaden als foutpaden test, inclusief formuliervalidatie en bevestigingsdialoogvensters en hoe je flows per functie organiseert voor een onderhoudbare E2E-testsuite. Hierna integreren we Maestro-tests in een GitHub Actions CI-pipeline om regressies automatisch bij elke pull request op te sporen.

Gratis beginnen

Leer JavaScript met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 30
Lessen: 120

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Gebruikersreizen met meerdere schermen testen” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad React Native Academy, waaronder “Gebruikersreizen met meerdere schermen testen”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus React Native Academy bevat in totaal 4 lessen.

Wat leer ik in “Gebruikersreizen met meerdere schermen testen”?

Schrijf een Maestro-flow voor aanmelden, onboarding en het gebruik van kernfuncties op meerdere schermen, waarbij u inputText en tapOn gebruikt om elke stap uit te voeren. Je oefent met React Native Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met React Native Academy te beginnen?

Ervaring vooraf is niet nodig. React Native Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.

Hoe lang duurt de les “Gebruikersreizen met meerdere schermen testen”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over React Native Academy?

Ja. Elke les over React Native Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

Maestro installeren en uw eerste flow uitvoeren
Assertions en wachten op elementen
Gebruikersreizen met meerdere schermen testen
Maestro in CI met GitHub Actions

← Terug naar React Native Academy