TestSupport-Tool Tutorial

Zielgruppe: Java-Entwickler mit Grundkenntnissen in Maven — Vorwissen zum TestSupport-StateMachine-Tutorial hilft

Inhaltsverzeichnis

Was ist TestSupport-Tool?
Wozu dieses Re-Build?
Die TestSupport-Familie
Voraussetzungen & Setup
Build & Start
Multi-Modul-Struktur
Demo-Mode (CLAUDE_MODE)
Die Handler
Der Prozess-Ablauf
Die GUI
LogSearcher & XmlSearcher
Env-Lock
Tests
Nächste Schritte

1. Was ist TestSupport-Tool?

TestSupport-Tool ist ein Activiti-freier Re-Build des internen testsupport_client. Es automatisiert End-to-End-Tests gegen ein internes System, inkl. Prozess-Steuerung, GUI, Log-Analyse und XML-Diff-Vergleiche.

Statt einer Activiti-Engine mit BPMN-XML nutzt das Projekt die leichtgewichtige TestSupport-StateMachine-Library — damit entfällt ein großer Dependency-Stack (Spring, H2, Jersey, Apache HttpComponents, Groovy, ...).

Projekt-Status: Aktive Portierung. Das Kern-Framework (Engine, Handler, GUI, LogSearcher, XmlSearcher) läuft im Demo-Mode End-to-End. Echte REST-Integration wird schrittweise reaktiviert.

⇧ nach oben

2. Wozu dieses Re-Build?

Das Original testsupport_client funktioniert produktiv einwandfrei — aber der Wartungsaufwand ist hoch:

Problem im Original	Lösung hier
Activiti-Engine + BPMN-Editor nötig	Prozess als Java-Code mit StateMachine-Library
Dependency-Graph ~40 Libraries	Reduziert auf das Wesentliche
H2/PostgreSQL als Prozess-DB	Kein persistenter Zustand — nur `ProcessContext` im RAM
BPMN-XML-Diffs im Git schwer zu reviewen	Java-Diffs sind Standard-Werkzeug
Debugging über Engine-State	Normaler Java-Debugger

Die Handler-Logik selbst wird nicht neu geschrieben, sondern aus dem Original 1:1 portiert — das garantiert Verhaltensäquivalenz.

⇧ nach oben

3. Die TestSupport-Familie

Das Projekt lebt in einer Projekt-Landschaft mit vier verbundenen Repos:

Projekt	Rolle
testsupport_client	Activiti-Original. Quelle für Handler-Portierungen — Referenz-Verhalten
TestSupport-StateMachine	Engine-Library (Activiti-Ersatz) — Dependency dieses Projekts
TestSupport-Tool	Dieses Projekt — Activiti-freier Re-Build
ITSQ-Testfaelle	Test-Set-Lieferant (`test_set/`-Artefakt wird per maven-dependency-plugin nach `X-TESTS/ITSQ` entpackt)

⇧ nach oben

4. Voraussetzungen & Setup

Software	Version	Zweck
Java JDK	21 oder höher	Compile + Runtime
Maven	3.6+	Build-Tool
Git	beliebig	Quellcode + Test-Daten-Referenz
TestSupport-StateMachine	1.0.0-SNAPSHOT	Engine-Library (muss lokal installiert sein)

Installation der StateMachine-Library

git clone https://github.com/CavdarKemal/TestSupport-StateMachine.git
cd TestSupport-StateMachine
ci.cmd 11         # installiert die JAR ins lokale Maven-Repo

Clone des Tools

git clone https://github.com/CavdarKemal/TestSupport-Tool.git
cd TestSupport-Tool

⇧ nach oben

5. Build & Start

Build

# Ohne Tests (schnell)
ci.cmd 21

# Mit Tests (gründlich, WireMock + Jemmy)
cit.cmd 21

Headless im Demo-Mode starten

java -cp TestSupport-Core/target/testsupport-core-0.1.0-SNAPSHOT.jar:... \
     de.creditreform.crefoteam.cte.testsupporttool.auto.CteTestAutomatisierungMain \
     e:ENE -Demo:true

CLI-Argumente

Argument	Bedeutung
e:<env>	Umgebung (z.B. `ENE`, `GEE`, `ABE`)
-Demo:true	Demo-Mode aktiviert (keine echten REST-Calls)
d:<bool>	Alias für `-Demo`

Config-Files: Die Umgebungs-Parameter liegen in TestSupport-GUI/ENE-config.properties (bzw. GEE/ABE). Beim Start per e:ENE wird die passende Datei geladen.

⇧ nach oben

6. Multi-Modul-Struktur

Das Projekt ist ein Maven-Multi-Modul-Projekt. Die Trennung folgt dem Prinzip „Backend/GUI getrennt“, damit Headless-Läufe (z.B. in CI) nicht die Swing-Dependencies ziehen:

Modul	Zweck
TestSupport-Core	Headless-Engine, Handler, ProcessDefinition, CLI-Main
TestSupport-XmlSearcher	XML-Suche + Ref-Export-Vergleich (Backend-Logik)
TestSupport-LogSearcher	Log-Parsing + Suche (Backend-Logik)
TestSupport-GUI-Base	Basis-Swing-Komponenten (BaseView/BasePanel-Pattern, 1500+ Icons)
TestSupport-JvmDialog	JVM-Dialog (Start-Parameter, Heap-Einstellungen)
TestSupport-XmlSearcher-GUI	Swing-GUI zum XmlSearcher-Backend
TestSupport-LogSearcher-GUI	Swing-GUI zum LogSearcher-Backend
TestSupport-GUI	Haupt-GUI + Distribution-Assembly

⇧ nach oben

7. Demo-Mode (CLAUDE_MODE)

Der gesamte Code ist im Demo-Mode lauffähig — echte REST-Aufrufe an das interne System werden simuliert. Das ermöglicht:

Entwicklung ohne VPN und Test-Umgebung
Vollständige End-to-End-Durchläufe für Regressions-Tests
CI-Builds ohne externe Abhängigkeiten

Wie funktioniert der Demo-Mode?

// In jedem Handler:
if (ctx.isDemoMode()) {
    // Dummy-Wert setzen + kurz schlafen (Animation)
    Thread.sleep(DEMO_MODE_WAIT_TIME.toMillis());
    ctx.put("ctImportJobId", "demo-job-42");
    return StepResult.NEXT;
}

// Echter Pfad (nur wenn nicht demo):
JobExecutionInfo job = restService.startCtImport(...);
ctx.put("ctImportJobId", job.getId());

CLAUDE_MODE-Blöcke: In der aktiven Portierung sind Server-Calls teilweise noch auskommentiert und mit CLAUDE_MODE-Kommentaren markiert. Diese Blöcke werden schrittweise reaktiviert, sobald der Demo-Pfad grün ist.

⇧ nach oben

8. Die Handler

Jeder Handler entspricht einem userTask im ursprünglichen BPMN-Modell. Alle Handler erben von AbstractUserTaskRunnable, was die Preamble (Phase-Logging + Notify + DemoCheck) zentralisiert.

Handler-Muster

Muster	Beispiel	Typisches Verhalten
Einfache Aktion	`PrepareTestSystem`	Setzt Systemzustand, keine Rückmeldung abwarten
REST-Job-Start	`StartCtImport`	Startet einen Job per REST, merkt Job-ID im Context
Polling	`WaitForCtImport`	Pollt wiederholt bis Job fertig oder Timeout
Wait-Before	`WaitBeforeCtImport`	Thread-Sleep vor dem eigentlichen Start (Synchronisation)
Check/Verify	`CheckRefExports`	Vergleicht Ist-Output gegen Referenz-XML
Notification	`SuccessMail`, `FailureMail`	E-Mail-Versand am Prozess-Ende

Aktuelle Handler-Liste

Aus TestSupport-Core/.../handlers/: PrepareTestSystem, RestoreTestSystem, GeneratePseudoCrefos, StartCtImport, WaitForCtImport, WaitBeforeCtImport, StartBeteiligtenImport, WaitForBeteiligtenImport, WaitBeforBeteiligtenImport, StartBtlgAktualisierung, WaitForBtlgAktualisierung, StartEntgBerechnung, WaitForEntgBerechnung, StartExports, WaitBeforeExport, StartCollect, CheckCollects, CheckRefExports, CheckExportProtokoll, StartSftpUploads, CheckSftpUploads, StartRestore, StartUploads, SuccessMail, FailureMail.

⇧ nach oben

9. Der Prozess-Ablauf

Der Haupt-Prozess liegt in process.TestAutomationProcess bzw. für den GUI-Einsatz in gui.CteAutomatedTestProcess. Er entspricht 1:1 dem CteAutomatedTestProcess.bpmn des Originals:

ProcessDefinition subPhase = ProcessDefinition.builder("TestAutomationProcessSUB")
    .step(new StartCtImportHandler(...))
    .step(new WaitForCtImportHandler(...))
    .step(new StartBeteiligtenImportHandler(...))
    .step(new WaitForBeteiligtenImportHandler(...))
    // ... weitere ~20 Steps
    .build();

ProcessDefinition main = ProcessDefinition.builder("TestAutomationProcess")
    .step(new PrepareTestSystemHandler(...))
    .step(new ConditionalStep("TestTypeGateway",
        ctx -> "PHASE1_AND_PHASE2".equals(ctx.get("TEST_TYPE")),
        new GeneratePseudoCrefosHandler(...),
        new SkipPseudoCrefosHandler(...)))
    .step(new SubProcessStep(subPhase))         // Phase 1
    .step(new SubProcessStep(subPhase))         // Phase 2
    .step(new SuccessMailHandler(...))
    .onFailure(new FailureMailHandler(...))
    .finallyStep(new RestoreTestSystemHandler(...))
    .build();

Resume-Fähigkeit

Ein Prozess kann per ResumeAwareSubProcessStep an einem beliebigen Schritt fortgesetzt werden (relevant, wenn Phase 1 sauber lief, Phase 2 aber geändert werden muss). Das Highlighting im Diagramm zeigt dabei, welche Steps übersprungen werden.

⇧ nach oben

10. Die GUI

Die Haupt-GUI (Modul TestSupport-GUI) ist eine 1:1-Portierung der Original-Swing-GUI — inkl. aller ~1500 Icons. Aufbau:

Bereich	Zweck
Customers-Tab	Auswahl der Test-Kunden (MultiSelect aus Test-Set)
Results-Tab	Baumansicht der Test-Ergebnisse, Drill-Down bis zum einzelnen Check
Prozess-Diagramm-Tab	Live-gerenderter Prozess-Verlauf (via `ProcessDiagramRenderer`)
Log-Tab	Timeline-Logger mit Step-Timestamps
Tools-Menü	XmlSearcher, LogSearcher, JvmDialog
Start-/Abbruch-/Resume-Buttons	Steuerung der Engine-Ausführung

Design-View-Trennung

Alle GUI-Klassen folgen dem Pattern:

gui/design/ — reine Panel-Klassen (Layout, .jfd-Files)
gui/view/ — Business-Logik und Event-Handler
gui/model/ — Table-/Tree-Models

Haupt-Controller

Der ProcessController ersetzt den alten ActivitiProcessController. Er verbindet GUI-Events (Start/Abbruch) mit der ProcessEngine und verteilt ProcessListener-Events an die GUI-Tabs (Diagramm-Update, Log-Append, Result-Tree-Refresh).

⇧ nach oben

11. LogSearcher & XmlSearcher

LogSearcher

Parst Log-Dateien aus dem Test-Ziel-System und findet Fehler-Muster. Eigenständig nutzbar, aber integriert auch über das Tools-Menü der Haupt-GUI.

Backend: TestSupport-LogSearcher (86 Klassen portiert)
GUI: TestSupport-LogSearcher-GUI (Tree-View mit Suchfeld + Highlighter)

XmlSearcher

Vergleicht erzeugte XML-Exports gegen Referenz-XMLs (Rueck-Regressions-Tests). Nutzt xmlunit für strukturierten Diff.

Backend: TestSupport-XmlSearcher (31 Klassen portiert)
GUI: TestSupport-XmlSearcher-GUI (Tools-Menü-Integration)
Verwendet in CheckRefExports- und CheckCollects-Handlern

⇧ nach oben

12. Env-Lock

Eine Test-Umgebung (ENE/GEE/ABE) darf nur von einer Tool-Instanz gleichzeitig genutzt werden — sonst würden parallele Läufe einander die Testdaten zerstören.

Der Env-Lock ist ein Server-Socket auf einer Port-Range (nicht Einzelport, um Windows-Loopback-Reservierungen zu umgehen):

Beim Start prüft das Tool, ob der Lock-Port bereits belegt ist
Ist er frei, bindet sich das Tool — der Port bleibt offen bis Prozess-Ende
Beim Crash wird der Port vom OS freigegeben — kein Datei-Leck
SO_REUSEADDR ist gesetzt, um Test-Flakiness zu vermeiden

⇧ nach oben

13. Tests

Test-Typ	Tool	Abdeckung
Unit-Tests	JUnit 5 + AssertJ	Modelle, Utility-Klassen, Renderer
REST-Integration	WireMock (Standalone)	`TesunRestService`, REST-Job-Handler
GUI-Tests	Jemmy	Smoke-Tests für alle Panels, Resume-Dialog-Flow
XML-Vergleich	xmlunit	CheckRefExports-Logik
End-to-End	Jemmy + Engine	Vollständiger Start-Stop-Resume-Ablauf

Tests ausführen

# Alle Tests (dauert einige Minuten)
cit.cmd 21

# Nur ein Modul
cd TestSupport-Core
mvn test

# JaCoCo-Coverage-Report
mvn clean verify
# Report unter TestSupport-*/target/site/jacoco/index.html

Umgebungs-Abhängigkeit: Tests laufen immer gegen ENE — die Umgebung ist hart konfiguriert, damit Test-Ergebnisse reproduzierbar sind.

⇧ nach oben

14. Nächste Schritte

Zum Ausprobieren

Demo-Mode-Lauf: Per cit.cmd 21 alles bauen und per CLI im Demo-Mode starten — Logausgabe und Outcome beobachten
GUI starten: Distribution aus TestSupport-GUI/target/ entpacken und die .cmd-Datei ausführen
Prozess-Diagramm anschauen: Während eines GUI-Laufs den Prozess-Diagramm-Tab im Auge behalten — bei jedem Step-Wechsel aktualisiert sich das Bild
Resume ausprobieren: Einen Lauf starten, nach Phase 1 abbrechen und per Resume-Dialog mit geänderten Daten fortsetzen

Zum Weiterentwickeln

Fehlende Handler portieren: Handler aus testsupport_client/tesun_activiti/handlers/ in dieselbe Struktur hier übernehmen
CLAUDE_MODE-Blöcke reaktivieren: Schritt für Schritt echte REST-Calls wieder einschalten (mit isDemoMode()-Guard)
Eigenen Listener schreiben: Z.B. ein SlackNotificationListener für Team-Chat-Benachrichtigung bei Prozess-Ende

Links

⇧ nach oben

TestSupport-Tool Tutorial

Inhaltsverzeichnis

1. Was ist TestSupport-Tool?

2. Wozu dieses Re-Build?

3. Die TestSupport-Familie

4. Voraussetzungen & Setup

Installation der StateMachine-Library

Clone des Tools

5. Build & Start

Build

Headless im Demo-Mode starten

CLI-Argumente

6. Multi-Modul-Struktur

7. Demo-Mode (CLAUDE_MODE)

Wie funktioniert der Demo-Mode?

8. Die Handler

Handler-Muster

Aktuelle Handler-Liste

9. Der Prozess-Ablauf

Resume-Fähigkeit

10. Die GUI

Design-View-Trennung

Haupt-Controller

11. LogSearcher & XmlSearcher

LogSearcher

XmlSearcher

12. Env-Lock

13. Tests

Tests ausführen

14. Nächste Schritte

Zum Ausprobieren

Zum Weiterentwickeln

Verwandte Projekte

Links