Part 043 — Testing BPMN and Workers

1. Core mental model

Workflow testing is not only testing whether a diagram can start.

It is testing whether a business process can survive realistic state transitions, worker failure, duplicate execution, late events, timer behavior, human decisions, variable evolution, and integration side effects.

A BPMN model is executable control flow. A worker is side-effecting infrastructure. A process instance is long-lived state.

That means workflow testing must cover three layers:

Senior rule:

A workflow test suite is weak if it only proves the happy path completes.

For enterprise quote/order systems, the hard problems are usually not the first successful approval. They are amendment after partial fulfillment, cancellation during pending external callback, duplicate Kafka event, late RabbitMQ reply, stale human task completion, retry after PostgreSQL commit, and compensation after downstream timeout.

2. What workflow testing must prove

A serious workflow test strategy should prove at least this:

• the process can start with valid inputs;
• invalid inputs fail predictably before creating broken runtime state;
• each gateway route is reachable and intentional;
• every service task has a worker/delegate implementation;
• every user task has assignment, authorization, form data, and completion semantics;
• timers fire under testable clock control;
• messages correlate to the right instance;
• duplicate messages do not corrupt state;
• workers are idempotent under retry and duplicate execution;
• BPMN errors are caught by the intended boundary/event subprocess;
• technical failures become retry/incident, not silent completion;
• compensation path is executable and business-valid;
• variable mappings are compatible across subprocess/call activity boundaries;
• old process versions and new worker versions can coexist during rollout;
• observability signals exist for failed jobs, incidents, stuck tasks, and SLA breach.

Testing workflow is about proving invariants, not only code coverage.

3. Test taxonomy

Use multiple test types. Do not force every risk into one giant end-to-end test.

The goal is not maximum number of tests. The goal is risk coverage with the cheapest reliable test at the right layer.

4. BPMN structural testing

Before executing the process, validate the artifact.

Structural checks should catch:

• BPMN XML is parseable;
• process ID follows naming convention;
• service task job type/topic/delegate expression is present;
• user task has assignment metadata or documented dynamic assignment;
• timer expression is valid and not environment-specific hardcoding;
• message name and correlation key convention is followed;
• gateway outgoing flows have clear condition labels;
• default flow exists where needed;
• call activity has explicit version binding strategy if required;
• no large inline script or hidden business rule is embedded;
• no environment secret is present in model/config;
• documentation fields are not stale or misleading.

A lint test cannot prove business correctness, but it prevents low-quality model changes from entering CI.

5. BPMN scenario testing

Scenario testing answers:

Given this initial process data and this sequence of worker/task/message/timer outcomes, does the process reach the expected state?

Scenarios should be named by business behavior, not by diagram shape.

Weak test name:

shouldGoThroughGatewayA

Better test name:

quoteApproval_goesToPricingApproval_whenDiscountExceedsThreshold

Good scenario tests cover:

• approval accepted;
• approval rejected;
• approval timed out;
• manual intervention required;
• validation succeeds;
• validation fails with business error;
• downstream API transient failure;
• downstream API permanent business rejection;
• fulfillment partially succeeds;
• cancellation arrives while fulfillment is active;
• duplicate external event arrives;
• late external event arrives after process moved forward;
• compensation executes after partial side effect;
• incident is created after retry exhaustion.

6. Gateway path testing

Every meaningful gateway route should have at least one test.

For exclusive gateways, test:

• each conditional path;
• default path;
• missing/invalid variable;
• boundary value;
• expression exception behavior.

For parallel gateways, test:

• all branches complete;
• one branch fails;
• one branch waits on message/timer;
• join does not complete early;
• duplicate completion does not break state.

For inclusive gateways, test:

• one selected path;
• multiple selected paths;
• no selected path and default behavior;
• join waiting semantics.

For event-based gateways, test:

• each competing event wins;
• losing event arrives later;
• timer wins over message;
• duplicate message after winner is ignored or handled explicitly.

Gateway bugs are often business bugs disguised as diagram bugs.

7. Timer testing

Timer testing must be deterministic.

Do not rely on real time sleeps unless no alternative exists.

Test:

• timer start event creates instance at expected schedule;
• intermediate timer moves process forward;
• boundary timer interrupts expected activity;
• non-interrupting boundary timer creates escalation while task remains active;
• timer cycle repeats as intended;
• timer expression resolves from variable safely;
• timezone assumptions are explicit;
• SLA timer does not fire immediately because of wrong ISO duration/date;
• timer migration behavior is understood;
• retry timers and business SLA timers are not confused.

Bad test smell:

Thread.sleep(60000);

Better mental model:

• control the test clock where supported;
• use runtime/test APIs to advance time;
• assert active element before and after timer trigger;
• assert incident/failure when timer expression is invalid.

8. Message correlation testing

Message tests must prove correlation correctness.

Test:

• process waits for expected message name;
• message correlates using correct business/correlation key;
• wrong key does not correlate;
• wrong message name does not correlate;
• duplicate message is safe;
• late message after process moved past wait state is handled;
• message TTL/expiration behavior is understood;
• correlation failure produces observable signal;
• Kafka/RabbitMQ/API callback maps metadata consistently.

Message correlation is one of the most common failure points in event-driven workflow.

The test should assert not only that the process moves, but that the correct instance moves.

9. BPMN error and technical failure testing

A BPMN error is a modelled business deviation.

A technical exception is an execution failure.

Test both.

Common bug:

• worker reports a technical outage as BPMN business error;
• BPMN model treats temporary downstream failure as business rejection;
• process completes even though worker side effect failed.

A test suite should make that impossible to miss.

10. Compensation testing

Compensation must be tested like real business rollback.

Do not test only that the compensation handler node is visited. Test the business effect.

For example:

• reservation created;
• downstream step fails;
• compensation releases reservation;
• release operation is idempotent;
• compensation failure becomes visible;
• manual repair path exists if compensation cannot complete.

Compensation tests should include:

• successful compensation;
• compensation worker retry;
• duplicate compensation command;
• compensation after partial DB commit;
• compensation after external API unknown outcome;
• compensation audit trail;
• late event after compensation.

A saga is not reliable because it has a compensation symbol. It is reliable when the compensation behavior is executable, observable, and idempotent.

11. Human task testing

Human tasks need tests too.

Test:

• task is created for expected candidate group/user;
• task is visible only to authorized users;
• claim/unclaim rules are enforced;
• stale completion is rejected or safely handled;
• save draft does not complete task;
• validation runs before completion;
• required variables are present after completion;
• task completion moves process to expected next element;
• due date/follow-up/SLA metadata is set;
• escalation timer works;
• concurrent completion is handled safely;
• task audit event is written.

Human task bugs usually appear as operational confusion:

• user cannot find the task;
• wrong user can complete the task;
• task disappears unexpectedly;
• process waits forever after user action;
• task completed with invalid form data;
• business audit cannot prove who approved what.

12. Worker unit testing

Worker unit tests should isolate domain logic from engine plumbing.

A worker usually does these things:

1. read variables/input;
2. validate command;
3. call domain/application service;
4. write database state;
5. publish outbox/event if needed;
6. produce output variables;
7. complete/fail/throw BPMN error.

Test worker logic as a plain Java component where possible.

Core unit test cases:

• valid input maps to correct command;
• missing variable fails with clear classification;
• domain rejection becomes BPMN error or business path;
• transient dependency failure becomes retryable failure;
• permanent technical error becomes incident path after retries;
• duplicate job does not duplicate side effect;
• output variable shape is stable;
• logging includes correlation ID/process instance/job key without PII.

Avoid worker code that can only be tested by starting the full engine. That usually means the worker has poor separation of concerns.

13. Worker integration testing

Worker integration tests verify boundary behavior.

Use real dependencies where they matter:

• PostgreSQL/Testcontainers for transaction, locking, unique constraints, outbox, inbox;
• mock HTTP server for external API behavior;
• Kafka/RabbitMQ Testcontainers where event semantics matter;
• Redis Testcontainers if lock/cache/idempotency behavior matters;
• Camunda runtime if job activation/completion/failure contract matters.

Important integration scenarios:

• DB commit succeeds, job completion fails;
• DB commit fails, job is not completed;
• duplicate job after timeout sees processed-job record;
• outbox event is written atomically with business state;
• external API timeout has unknown outcome;
• worker crashes before complete;
• worker crashes after side effect before complete;
• graceful shutdown stops new job activation and finishes/abandons active jobs safely.

14. End-to-end process testing

End-to-end workflow tests are expensive. Use them for critical business flows.

A good E2E test should execute:

• public API start request;
• process instance creation;
• worker execution;
• DB state transition;
• message/event publication;
• human task completion if relevant;
• external callback/message correlation;
• final process completion or expected incident/fallout.

Do not assert only final status. Assert critical intermediate states:

• active element after start;
• created user task;
• outbox event;
• process variable summary;
• database status;
• emitted Kafka/RabbitMQ message;
• incident/failure metadata for negative tests;
• audit trail.

15. Camunda 7 testing concerns

Camunda 7 testing often centers on embedded process engine execution.

Important concerns:

• engine configuration in test must match production enough to catch transaction/history behavior;
• JavaDelegate tests should not require full engine unless testing BPMN wiring;
• async continuations require explicit job execution in tests;
• job executor is often disabled in unit tests, so jobs must be executed manually or through test utilities;
• external task workers need separate fetch-and-lock/complete/failure tests;
• history level differences can hide audit/query bugs;
• database dialect mismatch can hide production PostgreSQL issues;
• delegate classloading and expression/bean resolution need integration coverage.

Camunda 7-specific test smell:

The test passes because everything runs synchronously in memory, while production uses async jobs, DB transactions, retries, and multiple nodes.

If production uses async boundaries, test async boundaries.

16. Camunda 8 testing concerns

Camunda 8/Zeebe testing should reflect distributed worker behavior.

Important concerns:

• job workers are remote clients;
• job timeout can cause duplicate execution;
• process instance creation may be async;
• job activation is pull/streaming-oriented depending on client/runtime;
• Operate visibility can lag behind engine execution due to exporter/search pipeline;
• Tasklist/user task behavior may differ from pure process execution tests;
• connectors may need mock/fake integration or connector runtime tests;
• partitioning/backpressure behavior is not fully represented by simple unit tests;
• test runtime version must match deployed version.

For Camunda 8, keep separate tests for:

• BPMN process behavior;
• Java worker logic;
• worker-to-Zeebe contract;
• connector behavior if used;
• API integration;
• operational observability.

17. Testing process definitions with Camunda Process Test

For Camunda 8, Camunda Process Test is a Java testing library for BPMN processes and process applications. It supports runtime modes such as Testcontainers-based execution and remote runtime execution depending on setup.

Use it to test:

• process deployment;
• process instance creation;
• active element assertions;
• job completion/failure behavior;
• process completion;
• timer/message behavior where supported;
• process variables and expected outputs.

Do not assume it replaces all integration testing.

It proves process behavior under a controlled runtime. It does not automatically prove:

• production Kubernetes topology;
• real PostgreSQL business transaction behavior;
• real Kafka/RabbitMQ duplicate/replay semantics;
• operator workflow in Tasklist/Operate;
• security/tenant isolation;
• production performance.

18. Testcontainers strategy

Testcontainers are useful for workflow systems because they make integration tests reproducible.

Good candidates:

• PostgreSQL for business data and outbox/inbox tables;
• Kafka for replay, ordering, schema, consumer behavior;
• RabbitMQ for ack/redelivery/DLQ behavior;
• Redis for lock/cache/idempotency behavior;
• Camunda/Zeebe runtime where supported;
• mock HTTP service for external APIs.

Practical rules:

• keep unit tests fast and numerous;
• use Testcontainers for integration boundaries that matter;
• avoid one giant containerized E2E test suite that developers stop running;
• reuse shared containers/runtime carefully in CI to reduce time;
• make tests deterministic and isolated;
• clean state between tests;
• do not use production credentials/secrets in tests.

19. Contract testing between BPMN and workers

BPMN and workers communicate through a contract.

The contract includes:

• job type/topic/delegate expression;
• input variables;
• output variables;
• BPMN error codes;
• retry classification;
• timeout expectation;
• idempotency key;
• correlation/business key;
• authorization context;
• expected side effects.

A contract test should fail if:

• BPMN task job type changed but worker did not;
• worker expects variable orderId but BPMN sends order_id;
• worker outputs validationResult but gateway reads isValid;
• BPMN catches error code ORDER_REJECTED but worker throws ORDER_VALIDATION_FAILED;
• timeout is shorter than worker worst-case execution;
• variable payload shape changed without compatibility layer.

20. Testing variable mapping

Variable mapping errors are silent killers.

Test:

• start variables;
• input mapping into service task;
• output mapping from worker;
• local vs global variable scope;
• subprocess/call activity input/output mapping;
• null/missing variable behavior;
• object/JSON schema evolution;
• sensitive variable exclusion/redaction;
• large payload rejection or externalization.

For long-running process, test compatibility between old process variables and new worker code.

A new worker version should tolerate older variable shape unless all old instances are drained/migrated.

21. Testing integration with PostgreSQL/MyBatis

Critical test cases:

• worker updates business table and completes job;
• worker updates business table but fails to complete job;
• worker receives duplicate job and detects existing transition;
• optimistic lock conflict occurs;
• unique constraint prevents duplicate side effect;
• outbox row is inserted in same transaction as business change;
• inbox/processed-job table prevents duplicate message/job processing;
• MyBatis mapper returns expected row count;
• transaction rollback prevents partial DB state;
• process variable is not used as replacement for canonical DB state.

Do not mock away database transaction behavior for idempotency-critical workers.

22. Testing Kafka/RabbitMQ integration

Kafka tests should cover:

• event starts or correlates process;
• duplicate event;
• out-of-order event;
• replayed event;
• schema evolution;
• partition key/correlation key;
• outbox event publication;
• consumer offset behavior after failure.

RabbitMQ tests should cover:

• ack after successful processing;
• nack/requeue behavior;
• DLQ routing;
• retry delay interaction;
• duplicate redelivery;
• reply correlation;
• timeout waiting for reply;
• routing key mismatch.

Message tests are not complete until duplicate and late delivery are tested.

23. Testing Redis usage

Redis should be tested only where correctness depends on it.

Test:

• lock acquisition/release;
• lock TTL expiration;
• lock renewal if used;
• idempotency key TTL;
• cache miss fallback;
• stale cache behavior;
• Redis outage behavior;
• feature flag/kill switch behavior;
• rate limiter behavior under burst;
• no permanent workflow truth is lost when Redis is cleared.

Never design a test that assumes Redis lock alone guarantees exactly-once workflow execution. It does not.

24. CI pipeline gates

A practical CI pipeline for workflow changes should include:

1. model lint/validation;
2. BPMN/DMN scenario tests;
3. worker unit tests;
4. worker integration tests for changed workers;
5. process-worker contract tests;
6. API contract tests if workflow endpoints changed;
7. migration compatibility test if existing process version is affected;
8. security/sensitive-data scan for variables/forms/config;
9. artifact packaging and version tagging;
10. deployment dry run where possible.

Workflow CI should fail fast on obvious model/contract issues before running slow E2E tests.

25. Test data strategy

Do not use random ad-hoc process payloads.

Maintain test fixtures for meaningful business scenarios:

• standard quote approval;
• high-discount quote requiring approval;
• enterprise agreement approval;
• order validation success;
• order validation business rejection;
• order fulfillment partial success;
• order cancellation during fulfillment;
• amendment after active order;
• manual fallout case;
• SLA breach scenario;
• duplicate external event scenario;
• migration candidate scenario.

Each fixture should document:

• business meaning;
• required variables;
• expected process path;
• expected DB state;
• expected events/messages;
• expected audit record;
• expected observability signal.

26. Negative testing matrix

Every critical workflow should have negative tests.

27. Observability assertions in tests

For critical paths, assert observability side effects too.

Examples:

• logs contain correlation ID and process instance key;
• metrics increment on worker failure;
• audit event written for human approval;
• incident includes useful error classification;
• outbox event has trace/correlation metadata;
• no PII appears in log/incident payload;
• task aging/SLA metadata exists.

Production debugging starts with what tests forced developers to emit.

28. Anti-patterns in workflow testing

Avoid these:

• only happy-path completion tests;
• tests that sleep for timers;
• mocking the process engine for BPMN correctness;
• mocking the database for idempotency logic;
• no duplicate job/message tests;
• no old-version compatibility tests;
• tests tied to internal engine implementation instead of business behavior;
• no authorization tests for human task completion;
• no negative tests for missing variables;
• no assertion of incidents/failure metadata;
• E2E-only strategy that is too slow to run;
• local-only tests that CI cannot reproduce;
• test fixtures that do not represent real business cases.

29. Internal verification checklist

Verify in the actual CSG/team environment:

• Which Camunda version/runtime is used, if any.
• Whether Camunda 7, Camunda 8, or custom orchestration is used for tested flows.
• Where BPMN/DMN/forms are stored.
• Whether BPMN lint/model validation exists in CI.
• Whether process scenario tests exist.
• Whether worker unit tests exist.
• Whether worker integration tests use PostgreSQL/Testcontainers.
• Whether Kafka/RabbitMQ/Redis integration tests exist for workflow paths.
• Whether user task APIs have authorization/concurrency tests.
• Whether timers are tested deterministically.
• Whether message correlation failure is tested.
• Whether duplicate job/message tests exist.
• Whether BPMN error vs technical failure is tested separately.
• Whether compensation is actually tested.
• Whether process version compatibility is tested.
• Whether migration tests exist for changed active process versions.
• Whether CI blocks deployment on workflow test failure.
• Whether staging/prod-like operational drills exist.
• Whether runbook steps are validated by tests or exercises.
• Whether test data matches real CPQ/order lifecycle scenarios.

30. PR review checklist

Ask these questions during PR review:

• What process path did this change affect?
• Is there a test for every changed gateway route?
• Is there a test for worker success and failure?
• Is idempotency tested under duplicate execution?
• Are message correlation keys tested?
• Are timer/SLA paths tested?
• Are user task assignment/authorization/completion tested?
• Are BPMN error and technical failure separated in tests?
• Are compensation paths tested if side effects can be partially completed?
• Are process variables tested for shape, scope, sensitivity, and compatibility?
• Does the test cover old running instances if worker/variable contract changed?
• Does CI run the relevant tests automatically?
• Is there a rollback/forward-recovery test or at least a runbook validation?

31. Senior engineer heuristics

1. Test the process as state, not as a picture. Active elements, variables, jobs, tasks, messages, and incidents matter.
2. Every gateway branch is a business claim. Prove it.
3. Every worker is at-least-once unless proven otherwise. Test duplicate execution.
4. Every external callback can be late, missing, or duplicated. Test all three.
5. Every timer must be deterministic in tests. Sleeps are a smell.
6. Every compensation path is production logic. Treat it like normal code.
7. Every long-running variable is a compatibility contract. Test old shape with new worker code.
8. Every human task is an authorization boundary. Test who can see and complete it.
9. Every retry policy can become a retry storm. Test failure classification.
10. Every production runbook should have at least one rehearsal path. Otherwise it is documentation, not readiness.

32. Official documentation anchors

Use these as starting points, then verify exact deployed version:

• Camunda 8 Camunda Process Test documentation.
• Camunda 8 testing process definitions best practices.
• Camunda 8 Zeebe Process Test documentation for older/version-specific projects.
• Camunda 8 Java client and worker testing resources.
• Camunda 8 connector testing documentation if connectors are used.
• Camunda 7 JUnit/process engine testing documentation and Javadocs.
• Camunda 7 external task testing and job executor testing references.
• Testcontainers documentation for PostgreSQL, Kafka, RabbitMQ, Redis, and custom containers.

Documentation proves what the tooling can do. Your test suite must prove that the workflow is correct for the business process, worker implementation, database state, messaging behavior, security model, and production recovery path.