CC-Testframework

TypeScript-basiertes Test-Framework mit eingebauten Konventionen für Web, Desktop und Mobile.

Was ist CC-Testframework?

CC-Testframework ist ein End-to-End-Test-Framework für Web-, Desktop- und Mobile-Anwendungen. Es baut auf Playwright für Web und Appium für Desktop und Mobile auf — aber das ist nur das Fundament. Darüber hinaus bekommst du:

  • Eine dreischichtige Datei-Struktur, die Framework, deine app-spezifischen Helfer und Test-Cases voneinander trennt
  • Vorgefertigte Routinen für die häufigsten Aktionen (Clicks, Formular-Befüllen, Dialog-Behandlung, File-/PDF-Utilities, OTP, Credential-Verwaltung)
  • Einen AI-Agent für Test-Authoring — beschreibe in normaler Sprache was du willst, der Agent generiert Test-Steps, die zu den Konventionen deines Projekts passen
  • Self-Healing-Locators — wenn sich das UI ändert und ein Selector bricht, erholt sich das Framework automatisch und schreibt den Fix in deinen Code zurück
  • Einen visuellen Inspector — Elemente über Web, Desktop und Mobile via Browser-UI auswählen; das Framework macht daraus einsatzbereite Locators
  • Zweisprachige Step-Beschreibungen — Tests einmal schreiben, Testern in der Sprache zeigen, die sie am besten lesen
  • Eine stabile Public-API mit semver-disziplinierten Releases über npm + GitHub Packages

Du scaffoldest mit einem einzigen Befehl ein eigenständiges pm/-Projekt, installierst dessen Abhängigkeiten und schreibst Tests gegen deine Anwendung — der äußere Root deines Repos bleibt unangetastet.

Für wen ist das?

CC-Testframework ist für Teams gebaut, die ihre Zeit mit dem verbringen wollen, was sie testen — nicht mit dem Bau der Infrastruktur drumherum. Du bist hier richtig, wenn:

  • Dein Team eine neue E2E-Test-Suite startet und ein bewährtes Fundament sucht statt eines Greenfield-Scaffolding-Projekts
  • Dein Team bereits Playwright einsetzt und immer wieder dieselben Muster von Projekt zu Projekt neu erfindet (Ordnerstruktur, Action-Helfer, Assertions, Wait-Strategien)
  • Du plattformübergreifendes Testen evaluierst — Web plus Desktop plus Mobile — und einen einheitlichen Stack willst statt drei getrennter Frameworks
  • Du auch für deine manuellen Tester einen produktiven Weg willst — sie können in Worten beschreiben, was sie brauchen, und der AI-Agent macht daraus lauffähigen Code

Einsteiger werden schnell produktiv durch die Templates und den Quickstart. Erfahrene Tester profitieren von API-Konsistenz über mehrere Projekte hinweg.

Was macht es anders?

Der Mehrwert zeigt sich darin, wie viel weniger Reibung du im Alltag hast verglichen mit einem selbstgebauten Playwright-Wrapper.

  • Von Installation bis zum ersten grünen Test in unter einer Stunde — Templates, Config und eine funktionierende Beispiel-App sind vorverdrahtet; kein Framework-Scaffolding-Wochenprojekt nötig
  • Tests, die UI-Änderungen überleben — Self-Healing fängt kaputte Selektoren ab, schlägt einen Fix vor und (opt-in) schreibt ihn zurück, sodass er über Runs hinweg persistiert; weniger Zeit für Flaky-Suite-Feuerwehr nach jedem Frontend-Release
  • KI schreibt konformen Code, keinen Wildwuchs — der eingebaute Agent generiert Test-Steps, die automatisch deinen Naming-, Signatur- und Locator-Konventionen folgen; Reviews werden kürzer, weil keine Style-Drift aufgeräumt werden muss
  • Ein Stack, drei Plattformen — dieselben Konventionen, API-Oberfläche und Reports gelten für Web, Desktop und Mobile; neue Tester müssen das Framework nur einmal lernen
  • Vorhersehbare Evolution — semver-disziplinierte Releases mit bilingualem Changelog und etablierter Migrations-Story; Upgrades sind langweilig, was genau das ist, was du von deiner Test-Infrastruktur willst
  • Review-freundlich per Design — dreischichtige Datei-Struktur und durchgesetzte Konventionen halten PR-Reviews auf Business-Logik fokussiert statt auf Style-Debatten

Du bleibst auf bekannten Fundamenten (Playwright, Appium) — das Framework legt eine konsistente, opinionated Schicht drüber, ohne dich vom Underlying-Tool zu entkoppeln.

Wo anfangen

Die Zeilen unten folgen dem natürlichen Weg von der frischen Installation bis zum grünen Business-Flow-Test:

Was willst du tun? Hin zu
Installieren und dein Setup in 15 Minuten verifizieren Quickstart
Die dreischichtige Struktur verstehen Konzepte
Deine zu testende Anwendung mit einem CLI-Befehl registrieren Neue App scaffolden
Manuelle Registrierung, Electron, Mobile, oder eine bereits von Hand gebaute App verkabeln Neue App hinzufügen — vollständiger Guide
Bildschirm-Elemente als Controls modellieren Controls hinzufügen
Tester-taugliche TestSteps komponieren TestSteps bauen
Naming- und Re-Export-Konventionen lernen und einen TestCase komponieren Deinen ersten TestCase schreiben
Einen Test ausführen und einen Fehlschlag debuggen Ausführen und Debuggen
Die AUT zwischen Läufen offen lassen, während du debuggst Persistente Debug-Session
Automatische Locator-Reparatur einrichten Self-Healing Locators
Deine TestCases in einer CI-Pipeline ausführen CI-Integration
Einen noch nicht automatisierten Test-Step schreiben Custom Steps
Die Datei-/Naming-Konventionen verstehen, die der Pre-Commit-Hook prüft Skeleton Conventions
Step-Beschreibungen in der Sprache eines Testers zeigen Step-Description Localization
API-Keys, Test-Account-Passwörter und andere Secrets sicher speichern Credential Management
Ein gespeichertes Test-Account-Passwort in einem TestCase auslesen Credential Management — TS_GetPassword
Mit Dateien, Shell, Registry und System-Infos arbeiten OS-App
Dateien per SFTP oder FTP/FTPS übertragen FTP-App
Eine Signup-Mail, OTP oder Bestätigungslink verifizieren Email-App
Einen fertigen TestCase gegen eine mitgelieferte Beispiel-App laufen lassen Demo Web App
Setup-Probleme lösen FAQ
Die kuratierte API durchblättern API-Referenz

💡 Update von vor v0.22.0? Die TestSteps der OS-, FTP- und Utilities-Apps haben ihre führenden refId-/pageLogName-/sectionName-Argumente verloren — siehe die Migrations-Hinweise in OS-App, FTP-App und Credential Management.

💡 Update von vor v0.24.0? Das gescaffoldete Projekt-Layout zog in einen einzigen pm/-Ordner um, drei Ordner wurden umnummeriert und Referenz-Screenshots verschoben — siehe Konzepte — Migration auf v0.24.0.

💡 Update von vor v0.25.0? pm/ wurde zu einem eigenständigen npm-Projekt — package.json, tsconfig.json, playwright.config.ts und .npmrc zogen aus dem äußeren Repo-Root in pm/ selbst um, und npm install/npx playwright test laufen jetzt aus pm/ heraus — siehe Konzepte — Migration auf v0.25.0.

Lizenz und kommerzielle Nutzung

CC-Testframework ist unter der Open Code License der itsbusiness AG lizenziert. Nach Lizenz-Erwerb darf der Lizenznehmer den Source-Code installieren, nutzen, für interne Verwendung modifizieren und in eigene Produkte integrieren — aber nicht weitervertreiben oder ein konkurrierendes Produkt entwickeln. Die vollständigen Bedingungen findest du in der LICENSE-Datei, die mit jedem Release ausgeliefert wird.

Für Lizenz-Anfragen, Preise oder kommerziellen Support: 📧 sales@itsbusiness.ch

itsbusiness AG · Bern · Schweiz