Examples Tables vs call read with Runtime Data in Karate Data-Driven Tests

Answer

In Karate 1.4.0 (the version referenced in the research), a Scenario Outline with an Examples: table renders each row as an independent scenario node in the HTML report. A failure therefore shows the outline name together with the exact example values, making it easy to pinpoint the offending data set. When you use call read() to invoke a feature with a runtime‑built JSON array, the HTML report does **not** create separate scenario nodes; the failure appears as a step inside the caller scenario, showing the called‑feature name and the iteration index (if you expose it via karate.repeat or an each loop) but not a distinct scenario title.

Why the difference?

• The outline expansion happens at compile‑time, so the runner treats each expanded row as a separate test entity.
• call read() is a runtime step; the called feature is executed as a sub‑routine of the caller, so the reporter nests it under the caller’s scenario.

Parallel distribution

With parallel execution enabled (karate.configure('parallel', true)) the JUnit 4, JUnit 5, and CLI runners distribute Outline rows across workers because each row is a separate test scenario. Rows processed inside a call read() loop stay on the same worker that invoked the caller, because the loop runs sequentially within that scenario.

Verification steps (you can run these locally)

1. Create a feature outline.feature with a Scenario Outline and an Examples: table of three rows; make the second row fail an assertion.
2. Run with parallel=true (JUnit 5 example: mvn test -Dkarate.parallel=true) and open target/karate-reports/outline.feature.html. You should see three scenario nodes; the failed one shows the example values.
3. Create a feature caller.feature that builds a JSON array at runtime (e.g., * def data = [{id:1},{id:2},{id:3}]) and calls called.feature via call read('called.feature') data. Inside called.feature fail on the second element.
4. Run the same parallel configuration and open the report for caller.feature.html. You will see only one scenario node (the caller); the failure appears as a step inside the called feature, labelled with the iteration index (if you logged karate.index or similar).
5. To confirm thread distribution, add karate.configure('trace', true) or inspect the console logs; you will see Outline rows executed on different worker threads, while the call read() loop runs entirely on the thread that started the caller.

Missing diagnostic detail

If you are using a Karate version older than 0.9.0 or a custom runner configuration, the behavior described above may differ. Please confirm your Karate version and whether you are running with JUnit 4, JUnit 5, or the CLI so I can verify that the recommendation applies to your setup.