Integrationstests mit der TestCaseFixture

Das Paket ProcessCube.Engine.TestCaseFixture deployt und führt BPMN-Testfälle gegen eine echte ProcessCube® Engine aus. Die ProcessModelTestCaseFixture startet dazu wahlweise eine Engine in einem Docker-Container oder verbindet sich mit einer bereits laufenden Engine.

Docker muss lokal verfügbar sein. Für das Debugging der Prozesse empfiehlt sich das ProcessCube® Studio.

Der Default in DockerImageReference zeigt seit v5.0.0 auf den ProcessCube®-Marketplace:

Konstante	Wert
`DockerImageReference.DefaultDockerImageName`	`marketplace.processcube.io/processcube-io/processcube_engine`
`DockerImageReference.DefaultVersionTag`	`20.3.0`

Breaking Change (v5.0.0): Der Default verweist nicht mehr auf 5minds/processcube_engine. Wer das Standard-Image nutzt, muss sich einmalig am Marketplace anmelden:


docker login marketplace.processcube.io

Die Fixture liest Docker-Credentials automatisch aus dem lokalen Docker-Setup (~/.docker/config.json inkl. credsStore/credHelpers). Ist das Image lokal bereits vorhanden, wird der Registry-Roundtrip übersprungen.

Setup

Eine Fixture-Klasse hält eine ProcessModelTestCaseFixture und gibt sie in Dispose() wieder frei (die Fixture hält unmanaged Ressourcen):


using ProcessCube.Engine.Testing.Fixtures;
 
public class Fixture : IDisposable
{
    public Fixture()
    {
        ProcessModelTestCaseFixture = new ProcessModelTestCaseFixture(
            containerSettings: new ContainerSettings
            {
                ContainerRetentionStrategy = ContainerRetentionStrategy.InCaseOfErrors
            },
            imageReference: DockerImageReference.Default);
    }
 
    public ProcessModelTestCaseFixture ProcessModelTestCaseFixture { get; }
 
    public void Dispose() => ProcessModelTestCaseFixture.Dispose();
}

Alternativ lässt sich eine bereits laufende Engine per ProcessEngineReference verwenden — dann wird kein Container gestartet:


ProcessModelTestCaseFixture = new ProcessModelTestCaseFixture(
    new ProcessEngineReference("http://localhost:56000"));

ContainerSettings

Einstellung	Standard	Beschreibung
`Host`	`localhost`	Host, unter dem der Container erreichbar ist
`HostPort`	freier Port	Host-Port (automatisch ein freier TCP-Port)
`ContainerRetentionStrategy`	`Never`	Behalten des Containers: `Never`, `InCaseOfErrors`, `Always`
`SpinUpCheckInterval`	`1s`	Prüfintervall beim Hochfahren des Containers
`SpinUpCheckLimit`	`30s`	Maximale Wartezeit, bis die Engine bereit ist
`ContainerName`	`null`	Optionaler fester Container-Name

Testfall definieren und ausführen

CreateTestCase() konfiguriert den Testfall über einen Builder; ExecuteAsync() führt ihn aus. Das using stellt die korrekte Freigabe sicher:


using var testCase = fixture.ProcessModelTestCaseFixture.CreateTestCase(config =>
{
    config.DeployProcessDefinitionFile("pfad/MeinProzess.bpmn")
        .StartProcessWith("StartEvent_1", new { SomeVariable = "someValue" })
        .ShouldEndWith("EndEvent_1")
        .WithExecutionTimeout(TimeSpan.FromSeconds(10));
});
 
await testCase.ExecuteAsync();

Builder-Methoden

Methode	Beschreibung
`DeployProcessDefinitionFile(path)`	BPMN-Datei als primäres Prozessmodell deployen
`DeployAdditionalProcessDefinitionFile(path)`	Weitere BPMN-Datei deployen (z.B. Sub-Prozesse)
`StartProcessWith(startEventId, token)`	Start-Event und Start-Token festlegen
`ShouldEndWith(endEventId)`	Erwartetes End-Event, das der Prozess erreichen muss
`WithExecutionTimeout(timeSpan)`	Timeout, nach dem der Testfall fehlschlägt
`RaiseSignal(name, delay)`	Signal nach Verzögerung auslösen (Signal Catch)
`HandleSignal<T>(name, handler)`	Geworfenes Signal samt Payload prüfen (Signal Throw)
`RaiseMessage(name, delay)`	Message nach Verzögerung auslösen (Message Catch)
`HandleMessage<T>(name, handler)`	Geworfene Message samt Payload prüfen (Message Throw)
`HandleUserTask(elementId, handler)`	User Task mit `UserTaskResult` beantworten
`HandleExternalTask<TIn, TOut>(topic, handler)`	External-Task-Worker simulieren
`OverrideTimerEvent(elementId, timeSpanOrDate)`	Timer-Event für den Test verkürzen

Debugging mit dem ProcessCube® Studio

Ist ContainerRetentionStrategy auf InCaseOfErrors oder Always gesetzt, bleibt der Container nach einem Fehler erhalten. Im ProcessCube® Studio lässt sich unter Connections eine Verbindung zur Container-URL anlegen und die Prozessinstanzen (finished, running, terminated, error) im Debugger inspizieren.