Übungsaufgaben zu End-to-End-Tests mit Playwright: Mitfahrgesuche im Browser prüfen

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „End-to-End-Tests mit Playwright:
Mitfahrgesuche im Browser prüfen“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/vue-e2e-akzeptanztest-playwright
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/vue-e2e-akzeptanztest-playwright-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Playwright
- End-to-End-Test
- Abnahmetest
- Kundentest
- Locator
- Auto-Waiting
- page.route
- Trace Viewer
- instabile Tests
- Vue 3

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je Locator 1 Punkt:

page.getByRole('heading', { name: 'Offene Gesuche' })                    // (1)
page.getByRole('status')                                                  // (2)
page.getByRole('listitem').filter({ hasText: 'Bielefeld' })
  .getByRole('button', { name: 'Zurückziehen' })                          // (3)
page.getByLabel('Datum')                                                  // (4)

Bei (3) ist auch page.getByTestId('gesuch-4').getByRole('button', { name: 'Zurückziehen' }) richtig; das Team nimmt data-testid aber erst, wenn nichts Sichtbares eindeutig ist, und der Ort ist hier sichtbar. Für (1) genügt auch getByRole('heading', { level: 2 }), solange es nur eine solche Überschrift gibt.

Je Beurteilung 1 Punkt:

1. Findet heute den richtigen Button, hängt aber an Aufbau und Reihenfolge: Kommt ein Gesuch hinzu oder ändert sich die Sortierung, klickt der Test ein anderes Gesuch an, ohne dass die App einen Fehler hat.
2. Findet drei Buttons; Locator sind strikt, click() bricht mit „strict mode violation … resolved to 3 elements“ ab. Er muss auf einen Listeneintrag eingeschränkt werden.
3. getByText() sucht ohne exact nach Teiltexten, ohne Groß- und Kleinschreibung zu beachten, und findet drei Elemente: „Offene Gesuche“, „3 Gesuche“ und den Button „Gesuch einstellen“. Für die Meldung passt getByRole('status').

Je Zeile 1 Punkt:

1. Wartet: Vor dem Klick prüft Playwright, ob der Button im DOM hängt, sichtbar und stabil ist, Ereignisse empfängt und aktiv ist (Actionability Checks).
2. Wartet nicht auf die Bedingung: count() zählt sofort einmal, expect() vergleicht nur noch einen Wert. Ist die Liste noch nicht geladen, ist das Ergebnis falsch.
3. Wartet: Web-First Assertion, Playwright sucht das Element wiederholt und vergleicht, bis der Text stimmt oder die Zeit (Standard 5 Sekunden) abgelaufen ist.

import type { Page } from '@playwright/test'

/** POST /v1/gesuche nachbilden: Kaffeetasse hat für den 19.11.2026 zur Schule schon ein Gesuch. */
export async function bildeGesucheNach(page: Page): Promise<void> {
  await page.route('**/v1/gesuche', async (route) => {
    const anfrage = route.request()
    if (anfrage.method() !== 'POST') {
      return route.fallback() // andere Methoden: an frühere Routen weitergeben
    }
    const neu = anfrage.postDataJSON()
    if (neu.datum === '2026-11-19' && neu.richtung === 'zur-schule') {
      return route.fulfill({
        status: 422,
        contentType: 'application/problem+json',
        json: {
          type: 'https://mitfahrlabor.example/probleme/gesuch-doppelt',
          title: 'Fachregel verletzt',
          status: 422,
          detail: 'Für diesen Tag und diese Richtung hast Du schon ein Gesuch.',
        },
      })
    }
    return route.fulfill({ status: 201, json: { id: 5, mitfahrerId: 3, status: 'offen', ...neu } })
  })
}

Bewertung: Route mit passendem Muster (1 Punkt), andere Methoden mit route.fallback() oder route.continue() weitergeben (1 Punkt), Body mit postDataJSON() lesen und die Regel prüfen (1 Punkt), 422 mit Problem Details und passendem Content-Type (1 Punkt), 201 mit ID 5 und den gesendeten Feldern (1 Punkt). Der Typ der Problem Details folgt im Projekt der Konstante PROBLEM_BASIS; jede eindeutige Adresse ist richtig.

import { expect, test } from '@playwright/test'
import { KAFFEETASSE, meldeAnAls } from './hilfen/anmeldung'
import { bildeGesucheNach } from './hilfen/gesuche'

test.describe('Gesuch einstellen', () => {
  test.beforeEach(async ({ page }) => {
    await bildeGesucheNach(page)
    await meldeAnAls(page, KAFFEETASSE)
    await page.goto('/gesuche/neu')
  })

  test('KT-1: Kaffeetasse stellt ein Gesuch ab Herford ein', async ({ page }) => {
    await page.getByLabel('Haltepunkt').selectOption({ label: 'Herford' })
    await page.getByLabel('Richtung').selectOption({ label: 'zur Schule' })
    await page.getByLabel('Datum').fill('2026-11-24')
    await page.getByLabel('Frühestens').fill('07:00')
    await page.getByLabel('Spätestens').fill('07:30')

    const gesendet = page.waitForRequest((r) => r.url().endsWith('/v1/gesuche') && r.method() === 'POST')
    await page.getByRole('button', { name: 'Gesuch einstellen' }).click()

    await expect(page.getByRole('status')).toHaveText('Gesuch 5 eingestellt')
    expect((await gesendet).postDataJSON()).toEqual({
      haltepunktId: 2,
      richtung: 'zur-schule',
      datum: '2026-11-24',
      zeitVon: '07:00',
      zeitBis: '07:30',
    })
  })
})

Bewertung: Nachbildung und Anmeldung vor goto() (1 Punkt), Felder über getByLabel() und selectOption()/fill() (2 Punkte), Button über getByRole() (1 Punkt), Meldung mit Web-First Assertion (1 Punkt), gesendeter Body geprüft (1 Punkt). waitForRequest() muss vor dem Klick angelegt werden, sonst kann die Anfrage schon vorbei sein. Ebenso richtig: den Body in bildeGesucheNach() in einer Variablen festhalten und nach der Meldung prüfen. Datumsfelder füllt fill() immer im Format JJJJ-MM-TT, unabhängig von der Anzeige im Browser.

test('KT-2: Ein zweites Gesuch für denselben Tag zeigt die Meldung des Backends', async ({ page }) => {
  await page.getByLabel('Haltepunkt').selectOption({ label: 'Herford' })
  await page.getByLabel('Datum').fill('2026-11-19')
  await page.getByLabel('Frühestens').fill('07:00')
  await page.getByLabel('Spätestens').fill('07:30')
  await page.getByRole('button', { name: 'Gesuch einstellen' }).click()

  await expect(page.getByRole('alert')).toHaveText('Für diesen Tag und diese Richtung hast Du schon ein Gesuch.')
  await expect(page.getByRole('status')).toBeEmpty()
})

Bewertung: Eingaben ohne Richtung, weil „zur Schule“ vorausgewählt ist (oder mit, beides richtig) (1 Punkt), Meldung über getByRole('alert') (1 Punkt), fehlende Erfolgsmeldung geprüft (1 Punkt). Die Prüfung auf die leere Live-Region steht nach der Meldung; vorher wäre sie sofort erfüllt und ohne Aussage.

Sie zeigen, dass die Seite die Eingaben richtig schickt und beide Antworten richtig anzeigt (1 Punkt). Sie zeigen nicht, dass das echte Backend den Endpunkt so anbietet, die Fachregel so prüft und das Token annimmt; die Nachbildung beruht auf einer Annahme über die spätere API. Ein Test im Projekt backend bräuchte ein Backend mit POST /v1/gesuche, ein Konto im Realm und Daten, die vor jedem Lauf gleich sind (z. B. frisch gestartetes Backend), weil der Test ein Gesuch anlegt (1 Punkt).

test('KT-03.2: Backend nicht erreichbar', async ({ page }) => {
  // später registriert = wird zuerst gefragt: überschreibt für diesen Test die Route aus bildeBackendNach()
  await page.route('**/v1/angebote', (route) => route.abort('connectionrefused'))
  await page.goto('/')

  await expect(page.getByRole('alert')).toHaveText('Die Fahrten können gerade nicht geladen werden.')
  await expect(page.getByRole('listitem')).toHaveCount(0)
})

Bewertung: eigene Route vor goto() (1 Punkt), route.abort() statt einer Antwort mit Fehlercode (1 Punkt), Meldung über getByRole('alert') (1 Punkt), keine Fahrt (1 Punkt). Eine Antwort mit Status 503 wäre ein anderer Fall (Backend erreichbar, aber gestört); die App zeigt dafür dieselbe Meldung, KT-03.2 meint aber die fehlende Verbindung.

test('Token abgelehnt: Hinweis und Button „Neu anmelden“', async ({ page }) => {
  await page.route('**/v1/angebote', (route) =>
    route.fulfill({ status: 401, headers: { 'WWW-Authenticate': 'Bearer error="invalid_token"' } }),
  )
  await page.goto('/')

  await expect(page.getByRole('alert')).toContainText('Deine Anmeldung ist abgelaufen.')
  await expect(page.getByRole('button', { name: 'Neu anmelden' })).toBeVisible()
  await expect(page.getByText('Angemeldet als')).toHaveCount(0)
})

Bewertung: 401 mit WWW-Authenticate wie beim Resource Server (1 Punkt), Hinweis über getByRole('alert') mit toContainText(), weil der Button zum Text der Meldung gehört (1 Punkt), Button über Rolle und Namen (1 Punkt), kein Pseudonym (1 Punkt). Die Anmeldung aus meldeAnAls() bleibt nötig, sonst fragt die App das Backend gar nicht erst.

Passen mehrere Routen zu einer Anfrage, fragt Playwright sie in umgekehrter Reihenfolge ihrer Registrierung; die im Test registrierte Route kommt nach der aus beforeEach und wird zuerst gefragt (1 Punkt). route.fallback() gibt die Anfrage an die nächste passende, früher registrierte Route weiter; so kann eine Route nur bestimmte Fälle übernehmen und den Rest der allgemeinen Nachbildung überlassen (1 Punkt).

Je Angabe 1 Punkt, zum Beispiel:

• im Netzwerk-Tab die Anfrage GET /v1/angebote mit Status 401 und dem Header WWW-Authenticate in der Antwort,
• der Request-Header Authorization: Bearer …: Die App hat ein Token geschickt, das Backend hat es abgelehnt,
• im DOM-Schnappschuss nach dem Laden der Absatz mit role="alert" und dem Button, während der Kopf kein „Angemeldet als“ mehr enthält,
• in der Konsole ggf. die Meldung des Browsers zur Antwort 401,
• in der Zeitleiste die Reihenfolge: goto, Anfrage, Antwort 401, Erscheinen des Hinweises.

Nach dem Klick auf „Suchen“ lädt die App neu: Die Liste verschwindet, es steht „Fahrten werden geladen …“ da, bis die Antwort kommt. count() hat genau in diesem Moment gezählt und 0 Einträge gefunden (1 Punkt). count() und textContent() lesen sofort einmal; expect() vergleicht danach nur noch Zahlen bzw. Texte und wartet nicht (1 Punkt). Auf dem Teamrechner antwortet das nachgebildete Backend so schnell, dass die neue Liste meist schon steht, wenn gezählt wird; in der ausgelasteten Pipeline dauert es manchmal länger (1 Punkt). Nachstellen: VERZOEGERUNG=300 npx playwright test … (PowerShell: $env:VERZOEGERUNG = "300"), dann scheitert der Test bei jedem Lauf mit derselben Meldung (1 Punkt).

Je Schwäche mit Folge 1 Punkt:

• waitForTimeout(500): Jeder Lauf wird eine halbe Sekunde langsamer, und braucht die Liste einmal länger, hilft das Warten trotzdem nicht.
• #such-haltepunkt, form button und li: hängen an IDs, Aufbau und Elementtyp statt an dem, was Nutzende sehen. form button bricht, sobald das Formular einen zweiten Button bekommt; li zählt jeden Listeneintrag der Seite, auch aus einer anderen Liste.
• selectOption('1'): wählt über die Haltepunkt-ID, die niemand sieht; ändert sich die Reihenfolge oder ID in den Daten, filtert der Test still nach einem anderen Ort.
• Name ohne vollständige Nummer und ohne erwartetes Ergebnis: Im Bericht ist nicht erkennbar, welcher Kundentest gemeint ist.

// Lösung 3.1: kein festes Warten, Locator nach Rolle und Beschriftung, Assertions mit automatischem Wiederholen
test('KT-02: Filter nach Haltepunkt Gütersloh zeigt die Angebote 1 und 2', async ({ page }) => {
  await bildeBackendNach(page, { verzoegerungMs: Number(process.env.VERZOEGERUNG ?? 0) })
  await meldeAnAls(page, KAFFEETASSE)
  await page.goto('/')
  await expect(page.getByRole('status')).toHaveText('4 Fahrten gefunden')

  await page.getByLabel('Haltepunkt').selectOption({ label: 'Gütersloh' })
  await page.getByRole('button', { name: 'Suchen' }).click()

  await expect(page.getByRole('status')).toHaveText('2 Fahrten gefunden')
  await expect(page.getByRole('listitem')).toHaveCount(2)
})

Nachweis mit VERZOEGERUNG=800 npx playwright test e2e/instabil.spec.ts e2e/stabil.spec.ts: Der ursprüngliche Test scheitert mit „Expected: 2, Received: 0“, die neue Fassung ist grün; ohne Verzögerung sind beide grün.

Bewertung: Warten auf den Ausgangszustand statt waitForTimeout (1 Punkt), Feld über getByLabel() und Auswahl über die sichtbare Beschriftung (1 Punkt), Button über getByRole() (1 Punkt), Web-First Assertions für Anzahl und Meldung (1 Punkt), Nachweis mit Verzögerung (1 Punkt). Die erste Assertion vor der Suche ist wichtig: Ohne sie könnte die Suche starten, während die erste Liste noch lädt, und das Ergebnis der ersten Anfrage käme zuletzt.

Der Vorschlag macht die Pipeline öfter grün, behebt aber die Ursache nicht (1 Punkt). Mehr Wiederholungen verstecken instabile Tests: Ein echter Fehler, der nur manchmal auftritt (z. B. eine verspätete Antwort, die eine neuere überschreibt), würde ebenfalls weggewiederholt, und das Vertrauen in rote Tests sinkt (1 Punkt). Zwei Sekunden festes Warten verlängern jeden Lauf um zwei Sekunden je Stelle und reichen trotzdem nicht, wenn die Pipeline einmal langsamer ist. Besser: auf eine sichtbare Bedingung warten wie in c), Wiederholungen bei zwei lassen und jeden als „flaky“ gemeldeten Test wie einen roten behandeln (1 Punkt).