SonataFlow integration test using PostgreSQL

This document describes how you can test your integrated workflow application using PostgreSQL persistence.

The example described in this document is based on the serverless-workflow-callback-quarkus example application.


This document describes the process of launching and testing the artifact that is produced by the Quarkus builds, and verifying the interaction of the artifact with a PostgreSQL database instance. To perform this scenario and verify the service behavior, the following Quarkus annotations and tools are used:

Testing a workflow application using PostgreSQL persistence

You can test your workflow application using PostgreSQL persistence.

  1. Add the required test dependencies to the pom.xml file of your workflow application:

    Dependencies required for HTTP-based testing in JVM mode
    Add awaitility dependency in pom.xml

    The awaitility dependency allows the test to express the time expectations of an asynchronous system. For more information, see Awaitility website.

  2. Check the dependencies of PostgreSQL resources.

    The Quarkus Dev Services for Databases is enabled when a reactive or JDBC data source extension is present in the workflow application.

    Ensure that the pom.xml file of your workflow application contains the required dependency for PostgreSQL resources.

    JDBC persistence add-on dependency
    Quarkus JDBC PostgreSQL dependency
    Quarkus Agroal data source dependency
  3. To run the integration tests, add Apache Maven Failsafe plug-in in the pom.xml file of your workflow application.

    maven-failsafe-plugin in pom.xml plug-in section

    For more information about maven-failsafe-plugin, see Maven Failsafe Plugin documentation.

  4. Enable Quarkus Database Dev Services.

    The additional containers contain a full set of default configurations, including PostgreSQL Docker image name, default user, and default password. The required configuration to link the workflow application with the Quarkus Dev PostgreSQL container is automatically added to the integration test. Quarkus provides the properties such as quarkus.datasource.reactive.url, quarkus.datasource.jdbc.url, quarkus.datasource.username, or quarkus.datasource.password, when you start the container.

    For more information, see Quarkus Dev Services for Databases in Quarkus documentation.

  5. Create a test class and add the test annotations in the test class as shown in the following example:

    Example integration test annotations in a test class
    @QuarkusIntegrationTest (1)
    class CallbackRestIT { (2)
        static {
        void testCallbackRest() {
            String id = given() (3)
            await() (4)
                    .atLeast(1, SECONDS)
                    .atMost(30, SECONDS)
                    .with().pollInterval(1, SECONDS)
                    .untilAsserted(() -> given()
                            .get("/callback/{id}", id)
    1 Allows launching and testing the artifact that is produced by the Quarkus build. Also, supports testing of a JAR file, a native image, or a container image.
    2 Test name ends with 'IT' to identify which test needs to be executed as an integration test.
    3 Testing application interactions using REST Assured.
    4 await() allows the test to retry the validations until the verifications are declared or until the specified time expectation is expired.

    Once you specify the required resources and annotations, you can start testing the different interactions with the workflow application as described in Testing your workflow application using REST Assured document.

  6. To run the tests, execute the following command:

    Run the tests
    mvn clean verify

Found an issue?

If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!