**Prompt 13 — Playwright, Smoke, A11y

oder: Wenn man Code liest, den man nie selbst geschrieben hat**

Das Lesen von Code, den jemand anderes geschrieben hat, ist das eine. Etwas zu erdenken, die Umsetzung aus der Hand zu geben und dann auf den fertigen Code zu blicken, ist etwas völlig anderes.

Langsam fühlt es sich an wie Benjamin Lam – CTO (Chief Technology Officer). Die höchste technische Instanz. Derjenige, der die Vision vorgibt, aber den täglichen Code kaum noch sieht.

Nur dass ich hier nicht CTO eines Teams bin, sondern CTO eines LLMs.

06:00 Uhr, Cherry Tree Inn. „I Got You Babe.“

Zurück zum Prompt. Der Wecker klingelt. Punkt 06:00 Uhr. Im Radio läuft „I Got You Babe“ von Sonny & Cher. Und wie Phil Connors in Groundhog Day starte ich wieder in denselben Ablauf:

„Lies die SPEC.md vollständig. Du implementierst das Projekt strikt nach dieser Spezifikation. Du darfst keine eigenen Patterns, Libraries oder Strukturen erfinden.“

Codex bestätigt artig, dass alles gelesen und verstanden wurde. Und dann beginnt der nächste Tag im Fließband.

Prompt 12 — Playwright + Smoke + A11y

Der Auftrag:

Playwright Container

  • tests/playwright/
  • playwright.config.ts
  • Smoke‑Tests:
    • Startseite lädt
    • Login funktioniert
    • Employee‑Liste lädt
    • Employee‑Detail lädt

A11y Tests

  • axe-core Integration
  • Prüfe: headings, labels, aria-describedby, skip links

CI‑Ready

  • Tests müssen gegen den Compose‑Stack laufen
  • Reports als Artefakte erzeugen

Vorgabe: Erzeuge ausschließlich Code, der SPEC.md exakt entspricht.

Was Codex daraus gemacht hat

Playwright‑Setup

  • CI‑taugliche playwright.config.ts
  • Testpfad: tests/playwright/tests
  • Reporter: HTML, JUnit, JSON
  • Base‑URL konfiguriert
  • Container‑Setup für CI ergänzt

Smoke‑Tests

  • Startseite lädt
  • Login funktioniert
  • Employee‑Liste lädt
  • Employee‑Detail lädt
  • Testdaten werden über die API erzeugt, um Flakiness zu vermeiden

A11y‑Tests

Mit @axe-core/playwright:

  • headings
  • labels
  • aria-describedby
  • skip links
  • checkA11y(...) integriert

UI‑Erweiterungen

Damit die Tests überhaupt laufen:

  • /login (GET/POST) ergänzt
  • Login‑Formular mit Labels, aria‑Deskriptoren und Skip‑Link
  • Skip‑Link auch im Detail‑View ergänzt

CI‑Runner

  • ops/scripts/test-playwright.sh
  • Startet Compose‑Stack
  • Führt Playwright im Container aus
  • Reports werden als Artefakte abgelegt

Dokumentation

README erweitert:

  • Playwright‑Pfad
  • Reports
  • CI‑Run‑Befehl

Testing & Commit

  • PHP‑Syntax grün
  • Playwright‑Lauf scheitert erwartungsgemäß an fehlendem Docker
  • NPM‑Install scheitert an Registry‑Blockade
  • Screenshot‑Versuch scheitert mangels laufendem Stack

Commit: 14c6537 PR: “Add audit hooks middleware and employee export endpoint”

Review + Spec‑Abgleich

Der nächste Schritt: prüfen, ob Playwright wirklich spec‑konform läuft.

Prüffragen:

  • Läuft Playwright gegen den Compose‑Stack?
  • Sind Smoke‑Tests stabil?
  • Sind A11y‑Checks korrekt integriert?
  • Werden Reports erzeugt?

Gefundene Abweichungen & Fixes

1. Compose‑Stack‑Anbindung

Problem: Playwright nutzte localhost im Container → funktioniert nicht.

Fix: Base‑URL auf Compose‑Service http://nginx gesetzt.

2. Login‑Smoke‑Test war kein echter UI‑Flow

Problem: Login wurde API‑basiert getestet, nicht über das Formular.

Fix: Smoke‑Test klickt jetzt durch /login → Formular → Redirect → /.

3. Testdaten kollidierten

Problem: Mehrere Tests erzeugten identische Employees.

Fix: Eindeutige IDs/Namen pro Testlauf.

4. Runner war nicht robust

Problem: DB‑Init fehlte, Readiness‑Wait war unzuverlässig.

Fix:

  • migrate.sh / seed.sh werden ausgeführt, wenn vorhanden
  • Readiness‑Check verbessert

5. npm ci ohne Lockfile

Problem: npm ci bricht ohne Lockfile ab.

Fix: Runner nutzt jetzt npm install.

Verifiziert

  • A11y‑Checks laufen
  • Reports werden erzeugt
  • Smoke‑Tests sind stabil
  • CI‑Konfiguration spec‑konform

Commit: 708a27e PR: “Fix audit rule enforcement and consent scope log masking”

Fazit

Das Lesen von Code, den jemand anderes geschrieben hat, ist normal. Aber Code zu lesen, den eine KI geschrieben hat, während man selbst nur noch die Vision hält – das ist neu.

Ich sitze davor, schaue auf Playwright‑Tests, A11y‑Checks, CI‑Runner, Middleware‑Ketten. Ich sehe Struktur, ich sehe Qualität, ich sehe, dass alles „richtig“ aussieht.

Und gleichzeitig fühlt es sich fremd an.

Der erste echte Hands‑on‑Moment rückt näher. Die Frage bleibt:

Wie viel davon wird sich „richtig“ anfühlen – und wie viel „fremd“?