[Feature]: Run multiple jobs by step

[williamgarr]

Pre-flight checklist

• I searched existing issues and this feature has not been requested yet.

Problem Statement

When I tried to write a tests with multiple lines in a step, I saw only the first one was taken into account.
Considering the Gherkin syntax, I believed I could group same operations in the same steps.
In the example, I have multiple checks in a single step, but I also did the same to send multiple messages in input step.

Proposed Solution

Handle multiline operations in a single step :

• All ?
• Checks only ?
• Also scripts run ?

Alternatives Considered

Separate in single operation steps, but it can create huge tests in certain cases.

Affected Component

Cucumber / BDD Integration

Example Usage / API Sketch

Additional Context

No response

[nil-malh]

Hello @williamgarr,

Thanks for the feedback !

You can use the Batch Consumer to avoid repeated Then expected record based on schema for the same topic. You can check the documentation here.
When spawning a batch consumer KTestify's consumer will fetch the X latest record (based on your consumerDeltaTime & consumerReadTimeout) and will try to match each message with all the provided files. If one of the files does not match any of the provided files the test will fail early. I think this answers your issue.

Moreover, having multi-lines for assertions means spawning X amount of consumers on the same topic this causes two issues :

1. Offset skew across DataTable lines: If we allowed a multi-line DataTable for consumers, each line would independently call fetch(), which recalculates the seek timestamp as now - consumerDeltaTime in calculateDeltaTime(). Since now advances with each line's processing time, the computed seek offset drifts forward line by line. If a line's processing delay isn't absorbed by consumerDeltaTime, seekToOffset() can land past the target message's actual timestamp, causing it to be missed entirely. Here's a diagram made by Claude for your understanding :

2. Loss of cross-file matching: The Batch Consumer doesn't just fetch multiple records, it tries to match each record against all provided files, rather than pairing them in a fixed order. This makes it resilient to messages arriving in a different order than the files were listed, since it doesn't assume file N corresponds to the Nth message. A multi-line DataTable, by contrast, would spawn one independent consumer per line, each scoped to match a single expected record in isolation. That one-to-one, order-dependent pairing loses the any-to-all matching the Batch Consumer provides. A test could fail simply because messages arrived in a different order than the DataTable lines were written, even though every expected message was actually produced correctly.

Between the offset skew and the loss of cross-file matching, we'd rather keep the Batch Consumer as the supported path for asserting multiple records on the same topic. It's both more robust and gives you the matching behavior multi-line DataTables would otherwise lose. Let me know if that works for your use case, or if there's a gap the Batch Consumer doesn't cover yet.

[williamgarr]

Hello @nil-malh , ok I understand, I will try with Batch Assertions.

But considering we want to check the ordering of the messages (¤2) wouldn't it be possible to pin the now value to the step instead of the line ? Wouldn't it fix the offset skew issue ?