« Back to Glossary Index

Kurzdefinition

Testautomatisierung ist der Einsatz von Software, um Testaktivitäten auszuführen oder zu unterstützen – z. B. Testdesign, Testausführung und Ergebnisprüfung.
Für Camunda‑Prozesse bedeutet das: BPMN‑Modelle wie Code behandeln und ihr erwartetes Verhalten (Abläufe, Pfade, Fehlerfälle) automatisiert verifizieren.

Warum ist das bei Camunda besonders wichtig?

• Camunda führt Prozesse aus, die in BPMN 2.0 modelliert sind; die Engine orchestriert dabei Abläufe über Tasks, Events, Gateways und Integrationen.
• In Projekten mit Prozessautomatisierung (z. B. mit Camunda/BPMN) hilft Testautomatisierung, Änderungen am Prozessmodell oder an „Glue Code“ (Delegates/Worker) schnell gegen Regressionen abzusichern.

Welche Testarten sind für Camunda‑Prozesse üblich?

Camunda empfiehlt, Prozesse wie Software zu testen und dabei zwischen typischen Test‑Scopes zu unterscheiden: Unit‑Tests, Prozess‑Tests (prozesszentriert, schnell) und Integrations‑Tests (nah an Produktion).

1) Unit‑Tests (Code‑Ebene)

• Testet euren eigenen Code (z. B. FEEL/Business‑Logik, Java‑Delegates/Worker), ohne den kompletten Prozess auszuführen.

2) Prozess‑Tests (BPMN‑Verhalten)

• Testet den BPMN‑Ablauf inkl. Datenfluss, z. B. „Happy Path“, Timer‑Pfad, Fehler‑Boundary‑Event‑Pfad, Message‑Correlation‑Pfad.
• Diese Tests sollen häufig laufen und sich „wie Unit‑Tests“ anfühlen (schneller Turnaround, möglichst keine externen Abhängigkeiten).

3) Integrations‑Tests (System‑Kette)

• Verifizieren die Lösung in einer Umgebung, die Produktion möglichst ähnlich ist (inkl. externer Systeme, Deployments, ggf. human‑driven/exploratory Checks).

Tooling (kurzer Überblick)

Camunda 8

• Camunda Process Test (ab Camunda 8.8): Best‑Practice‑Ansatz für schnelle Prozess‑Tests, typischerweise mit JUnit 5, lokal/isolierter Engine und Assertions; Testcontainers/Docker wird als einfacher Weg genannt.
• Zeebe Process Test ist deprecated (ab 8.8, Removal ab 8.10) zugunsten von Camunda Process Test.

Camunda 7

• Camunda beschreibt Setup‑Bausteine wie JUnit, In‑Memory Engine (JobExecutor aus), @Deployment pro Test und camunda-bpm-assert für Prozesszustands‑Assertions sowie Mocking (z. B. Mockito).

Beispiele (Camunda‑Prozess)

Beispiel A: BDD/Gherkin (fachlich, gut fürs Wiki/Glossar)

Ein Beispiel für einen Freigabeprozess (z. B. Angebot/Antrag) mit Timer‑Eskalation und Fehlerbehandlung – typisch für BPMN‑Orchestrierung.

Feature: Freigabeprozess in Camunda (BPMN)

  Scenario: Freigabe innerhalb der SLA
    Given ein Vorgang wird gestartet
    When die Aufgabe "Freigeben" von einem Bearbeiter abgeschlossen wird
    Then wird der Vorgang als "genehmigt" beendet

  Scenario: Eskalation bei Überschreitung der Bearbeitungszeit
    Given ein Vorgang ist gestartet und wartet auf "Freigeben"
    When die definierte Bearbeitungsfrist (Timer) abläuft
    Then wird ein Eskalationspfad ausgeführt
    And der Vorgang wird entsprechend markiert (z. B. "auto-genehmigt" oder "eskaliert")

  Scenario: Technischer Fehler beim externen System wird abgefangen
    Given der Vorgang erreicht den Service-Schritt "Archivieren"
    When das Archivsystem einen Fehler liefert
    Then wird ein Fehlerpfad ausgeführt (z. B. manuelle Nachbearbeitung)

Warum das sinnvoll ist: Camunda betont, dass BPMN‑Prozesse wie Code behandelt und in ihren Pfaden getestet werden sollten.

Beispiel B: Automatisierter Prozess‑Test (Camunda 8, Java/JUnit 5 – konzeptionell)

Camunda empfiehlt für Camunda 8 schnelle Prozess‑Tests mit lokalisierter/isolierter Engine, JUnit 5 und der Camunda Process Test‑Bibliothek; Testcontainers (Docker lokal) wird als pragmatischer Weg erwähnt.

Hinweis: Das folgende Snippet ist bewusst konzeptionell (API‑Details variieren je nach Stack/Version). Es zeigt, was ihr prüft: gestarteter Prozess → Jobs/Tasks → erwarteter Zustand.

import org.junit.jupiter.api.Test;
// z. B. via @CamundaSpringProcessTest (Camunda 8)
class ApprovalProcessTest {

  @Test
  void happyPath_finishesApproved() {
    // given: BPMN deployed (z. B. via Test setup) [4](https://docs.camunda.io/docs/components/best-practices/development/testing-process-definitions/)

    // when: start process instance
    var instanceKey = startProcess("approval-process", Map.of("amount", 5000));

    // and: complete worker job / user task depending on model
    completeJob("validate");
    completeUserTask("approve"); // falls User Task
    completeJob("archive");

    // then: assert process ended and variables/state are correct
    assertProcessEnded(instanceKey);
    assertVariableEquals(instanceKey, "status", "APPROVED");
  }
}
``

Best Practice dahinter: Prozess‑Tests sollen häufig laufen, schnell sein und den Prozesszustand/Variablenfluss prüfen.

Beispiel C: Automatisierter Prozess‑Test (Camunda 7, JUnit Extension + Assertions)

Für Camunda 7 nennt Camunda u. a. JUnit, In‑Memory Engine (JobExecutor aus), @Deployment je Test und camunda-bpm-assert für lesbare Assertions; externe Services werden häufig gemockt (z. B. Mockito).

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.camunda.bpm.engine.test.junit5.ProcessEngineExtension;
import org.camunda.bpm.engine.test.Deployment;

import static org.camunda.bpm.engine.test.assertions.ProcessEngineTests.*;

@ExtendWith(ProcessEngineExtension.class)
class OfferApprovalProcessC7Test {

  @Test
  @Deployment(resources = "bpmn/offer-approval.bpmn")
  void timerPath_escalates_whenSlaExceeded() {
    // when: start instance
    var pi = runtimeService().startProcessInstanceByKey("offer-approval");

    // simulate timer / advance time (je nach Test-Setup)
    execute(job()); // e.g., execute due timer job

    // then: assert we are in escalation step / correct end state
    assertThat(pi).isWaitingAt("escalationTask");
  }
}
``

Warum das nützlich ist: Der Test bleibt nahe am Prozessmodell und deckt gezielt Pfade (z. B. Timer‑Eskalation) ab, ohne gleich eine komplette Systemumgebung aufzubauen.

Mini‑Checkliste: Was sollte bei Camunda‑Prozessen automatisiert werden?

• Happy Path (Standardablauf) + kritische Alternativpfade (Gateways).
• Timer/SLA‑Eskalationen (z. B. „zu lange offen“).
• Fehlerpfade (Boundary Error, Retry/Compensation/Manual Handling).
• Integrationspunkte (Service Tasks/Worker) mindestens via Mock/Contract oder als Integrations‑Test in produktionsnaher Umgebung.
• CI‑Einbindung: Tests in die Pipeline, damit jede Änderung automatisch gebaut und getestet wird.

Kurze Einordnung für nanoLogika‑Kontext

Wenn ihr Camunda zur Prozessmodellierung und -automatisierung einsetzt, liefert Testautomatisierung den „Sicherheitsgurt“, damit Prozessänderungen (BPMN/Delegates/Worker) nicht unbemerkt Nebenwirkungen erzeugen.

« Back to Glossary Index