Demo Web App

Eine kleine, in sich geschlossene ERP-artige Web-App, ausgeliefert als npm-Paket, plus ein sofort lauffähiger TestCase dagegen — der schnellste Weg, das Framework end-to-end in Aktion zu sehen, ohne selbst einen Locator zu schreiben.

← Zurück zur Übersicht · 🇬🇧 English · ← Deinen ersten TestCase schreiben

Was ist die Demo Web App?

@meintest/cc-testframework-demo-web ist ein separates npm-Paket mit einer kleinen, Vanilla-HTML/CSS/JS-“ERP”-Anwendung — Kunden, Produkte, Bestellungen — mit Login-Screen, Dashboard, Listen-/Detail-/Formular-Sichten, Bestätigungs-Dialogen und Toast-Benachrichtigungen. Sie wird vorgebaut ausgeliefert (dist/index.html + Assets) und läuft vollständig client-seitig: Der gesamte Zustand lebt im localStorage des Browsers, es geht nichts übers Netzwerk, und es gibt keine Server-Komponente zu starten oder zu konfigurieren.

Sie existiert, damit du eine realistische, deterministische App hast, gegen die du deinen ersten TestCase richten kannst — ohne bereits Zugriff auf deine eigene Anwendung zu brauchen, und ohne einen einzigen XPath von Hand zu schreiben. Das Framework liefert dazu ein passendes Controls-/TestSteps-Preset und einen vollständigen Beispiel-TestCase; du installierst das Paket, verdrahtest zwei Zeilen Config, und lässt in Minuten einen grünen End-to-End-Test laufen.

💡 Keine Produkt-Demo. Dies ist ein Test-Target, keine Sales-Vorführung. Ihr Zweck ist es, dir das dynamische Element-Lookup und Self-Healing des Frameworks an etwas Konkretem auszuprobieren zu lassen, bevor du eines von beiden gegen deine eigene Anwendung richtest.

Sehen, wo jede How-to-Seite hier auftaucht

Dieser Durchlauf ist genau derselbe Scratch-to-Green-Test-Weg, den der Rest der Doku beschreibt — nur bereits vorverdrahtet, sodass du jedes Teil an seinem Platz siehst, bevor du dein eigenes baust:

How-to-Seite Wo sie in diesem Durchlauf auftaucht
App hinzufügen Schritt 2 unten — GlobalConfig.apps auf die mitgelieferte dist/index.html richten
Controls hinzufügen Die mitgelieferten 1_Controls/*-Dateien, die das _ExampleWebApp-Preset vorinstanziiert mitliefert
TestSteps bauen Die mitgelieferten 2_Steps/*-Dateien — TS_Main_Login, TS_Main_VerifyToast und ähnliche
Deinen ersten TestCase schreiben Der Beispiel-TestCase weiter unten
Run and Debug TC_ExampleWebApp_HappyPath.spec.ts ausführen und seine Ausgabe lesen

Warum bewusst kein id-/data-testid-Attribut

Die meisten Tutorial-Demo-Apps liefern großzügige id="submit-button"-/data-testid="customer-row-3"-Attribute mit, was das Schreiben von Locators trivial macht — aber so sehen die meisten echten Anwendungen nicht aus. Legacy-Web-Apps, Third-Party-UIs und alles, was nicht mit Test-Automatisierung im Kopf gebaut wurde, bieten selten stabile Test-Hooks. Ein Framework, das nur gegen eine instrumentierte Tutorial-App überzeugend wirkt, sagt wenig darüber aus, wie es sich gegen die App verhält, die du tatsächlich testen musst.

Die Demo Web App ist andersherum gebaut: kein id, kein data-testid, kein data-cy-Attribut irgendwo (die eine Ausnahme — ein id, das rein für die native <label for="...">-Assoziation genutzt wird — ist nie als Test-Selector nutzbar). Elemente müssen so adressiert werden, wie ein Tester eine echte, nicht instrumentierte Anwendung angehen müsste:

  • Sichtbarer Text-Inhalt (Button-Labels, Table-Cells)
  • Semantische Rollen (<button>, <table>, <form>, <nav>)
  • CSS-Klassen als sekundäres Signal
  • Struktur-Position (z.B. “die Zeile, deren erste Zelle ‘Acme Corp’ liest”)

Manche Screens gehen bewusst noch weiter — mehrere identisch beschriftete “Edit”-/”Delete”-/”Confirm”-Buttons erscheinen in jeder Table-Zeile, sodass ein blankes Label-Lookup mehrdeutig ist, bis du Row-Context ergänzt. Das gibt der dynamischen Locator-Auflösung des Frameworks (siehe Konzepte) und den Self-Healing Locators etwas Realistisches, gegen das sie arbeiten können: Element-Adressen, die aus Struktur und Inhalt abgeleitet werden müssen, nicht von einem bequemen Attribut abgelesen — und, falls ein Locator nach einer Markup-Änderung je geheilt werden muss, eine App, die einer echten ähnlich genug ist, dass sich das geheilte Ergebnis verallgemeinern lässt.

// Aus der mitgelieferten Button-Control — kein id/data-testid weit und breit:
Core.xpath`.//button[normalize-space()='${label}']`

// Row-scoped Variante, nötig weil sich dasselbe Label pro Zeile wiederholt:
Core.xpath`.//tr[.//td[normalize-space()='${rowContext}']]//button[normalize-space()='${label}']`

💡 Vorerst englisch-only. Die Demo-Oberfläche ist derzeit englisch-only.

Wie du sie startest

1. Paket installieren

Aus pm/ heraus:

npm install --save-dev @meintest/cc-testframework-demo-web

Das Paket enthält nur einen vorgebauten dist/-Ordner (index.html, styles.css, app.js und dessen Module) plus dessen README.md und LICENSE — kein Source, kein Build-Schritt auf deiner Seite nötig.

2. GlobalConfig.apps darauf richten

2_Apps/1_Global/GlobalConfig.ts (deine aus den Templates gescaffoldete Projekt-Kopie) liefert dafür ein auskommentiertes Beispiel mit. Kommentiere es ein, oder füge selbst den entsprechenden Eintrag hinzu:

import { createRequire } from 'node:module';
const require = createRequire(import.meta.url);
const demoIndex = require.resolve('@meintest/cc-testframework-demo-web/dist/index.html');

export const apps = {
    ExampleWebApp: {
        type: 'Web',
        tool: 'Playwright',
        baseUrl: `file://${demoIndex}`,
    },
} as const;

require.resolve(...) findet die dist/index.html des installierten Pakets auf der Platte; baseUrl wird daraus eine schlichte file://-URL. Es ist kein HTTP-Server im Spiel — Core.defineExecutionStep des Frameworks navigiert den Browser direkt auf diese lokale Datei, genau so wie es auf jede https://-URL navigieren würde.

💡 Zero-Server-Story. Nichts muss auf einem Port lauschen, und nichts muss vor deinem Testlauf gestartet werden — npm install innerhalb von pm/ ist der einzige Setup-Schritt. Das macht die Demo Web App auch zu einem praktischen CI-Smoke-Target: kein Service hochzufahren, kein Port abzuwarten.

3. Das _ExampleWebApp-Preset scaffolden

Das Templates-Paket liefert einen vollständig vorinstanziierten App-Ordner — Controls, TestSteps und ihre .i18n.json-Kataloge — unter dem _ExampleWebApp-Preset, plus einen sofort lauffähigen TestCase. Beim Scaffolden eines neuen Projekts wählst du dieses Preset neben (oder statt) dem generischen _Skeleton; die 2_Apps/1_Global/References.ts deines Projekts re-exportiert es dann:

// 2_Apps/1_Global/References.ts
export * as ExampleWebApp from '../_ExampleWebApp/References';

Damit sind Project.ExampleWebApp.TS_Main_Login(...) und ähnliche bereit, aus jedem TestCase heraus aufgerufen zu werden — siehe Deinen ersten TestCase schreiben für die allgemeine Form, in der ein TestCase TestSteps zu einem Ablauf komponiert.

Feature-Tour

Screen Was du tun kannst
Login Anmelden mit admin / demo123; ein falsches Passwort zeigt einen Error-Toast, ein korrektes einen Success-Toast und leitet zum Dashboard weiter
Dashboard Kunden-/Bestellungs-/Produkt-Zähler sehen und über Quick-Actions in jeden Bereich springen
Kunden Sortierbare, filterbare Liste (15 seeded Zeilen); einen Kunden anlegen, bearbeiten, über ein Formular deaktivieren/reaktivieren
Produkte Preis-sortierbare Liste (10 seeded Zeilen)
Bestellungen Liste mit Status-Badges (Draft/Confirmed/Shipped/Cancelled); eine neue Bestellung mit durchsuchbarer Kunden-Combobox und Live-Summe anlegen; den Status einer Bestellung überführen (Confirm/Ship/Cancel)
Bestätigungs-Dialoge Erscheinen vor destruktiven Aktionen (z.B. Deaktivieren eines Kunden); bestätigen, abbrechen, per Escape schliessen, oder auf den Backdrop klicken
Toast-Benachrichtigungen Success-/Error-/Warning-Toasts oben rechts, verschwinden nach 3 Sekunden automatisch oder manuell schliessbar
Reset Data Ein Button im Footer löscht den gesamten lokalen Zustand und lädt die App zurück auf ihre deterministischen Seed-Daten — nützlich am Anfang oder Ende eines Testlaufs zur Isolation

Alle Daten bestehen aus 15 seeded Kunden, 10 seeded Produkten und 20 seeded Bestellungen; der Reset Data-Button kehrt immer zu genau diesem Ausgangspunkt zurück, sodass ein TestCase wiederholt laufen kann, ohne Zustand anzuhäufen.

Der Beispiel-TestCase

Das Templates-Paket liefert 3_Cases/TC_ExampleWebApp_HappyPath.spec.ts — einen vollständigen, für Tester lesbaren Happy-Path-Ablauf: App starten, einloggen, einen Kunden anlegen, für diesen Kunden eine Bestellung anlegen und bestätigen, den Kunden über den Bestätigungs-Dialog deaktivieren, die Daten zurücksetzen, ausloggen, App schliessen. Jeder Step ist ein schlichter Project.ExampleWebApp.TS_*(...)-Aufruf — kein page.locator(...), kein direkter Playwright-Aufruf irgendwo im TestCase-File.

// 3_Cases/TC_ExampleWebApp_HappyPath.spec.ts (Ausschnitt)
await Project.Core.Step.numberedStepBlock(`Login as admin`, async () => {
    await Project.ExampleWebApp.TS_Main_Login('', 'admin', 'demo123');
    await Project.ExampleWebApp.TS_Main_VerifyToast('', 'Login successful', 'Success');
    await Project.ExampleWebApp.TS_Main_VerifyCurrentUser('', 'admin');
});

Sobald das Paket installiert und die beiden Config-Schritte oben erledigt sind, läuft dieser TestCase ohne weitere Änderungen gegen dein gescaffoldetes Projekt — siehe Deinen ersten TestCase schreiben für die allgemeine Form, der ein TestCase folgt.

Wo es weitergeht

  • Deinen ersten TestCase schreiben — die Naming- und Re-Export-Konventionen, denen dieses Preset folgt
  • Konzepte — die Drei-Schichten-Architektur (Core / 2_Apps / 3_Cases), auf der das _ExampleWebApp-Preset aufbaut
  • Run and Debug — TC_ExampleWebApp_HappyPath.spec.ts ausführen und seine Ausgabe lesen
  • Self-Healing Locators — richte das gegen die Demo Web App ein, um automatische Locator-Reparatur in Aktion zu sehen
  • Quickstart — der allgemeine Installations- und Erster-Test-Ablauf, falls du den noch nicht durchlaufen hast

📧 Fragen? Kontakt: jens.szelag@itsbusiness.ch

itsbusiness AG · Bern · Schweiz