CAMEL-23688: camel-jbang - add unit tests for more action reader CLI commands

[ammachado]

Description

Batch C of the regression test coverage for the camel-jbang CLI action/ commands (CAMEL-23688), building on the merged Batch A (#24188) and Batch B (#24189). The JIRA asks for a regression safety net around these commands ahead of a planned refactor.

This batch adds unit tests for the remaining action commands whose behavior a unit test can deterministically reach, all in dsl/camel-jbang/camel-jbang-core:

Output.json round-trip readers (delete the stale <pid>-output.json, write <pid>-action.json, then poll for the response):

• CamelBrowseActionTest, CamelSpanActionTest, CamelRouteTopologyActionTest, CamelLoadActionTest, CamelStubActionTest

Named-pid request path of commands that otherwise spawn a background Camel:

• CamelSendActionTest, CamelReceiveActionTest, CamelRouteStructureActionTest — only the branch that targets an already-running integration is covered; the no-pid branches spawn a Camel via Run and are out of scope for unit tests.

Message-history reader:

• CamelHistoryActionTest — CamelHistoryAction reads a pre-existing <pid>-history.json rather than the action/output round trip, so a writeMessageHistoryFile helper is added to ActionCommandTestSupport and the test drives it via callWithSingleProcess.

Each test asserts intent (the action discriminator written to the action file and a specific rendered substring from the fixture), plus the no-match exit behavior, rather than merely checking a non-null result or exit code.

No production code is changed; this is test-only. The existing callWithResponse responder-thread harness (added in Batch B) is reused unchanged for the round-trip readers.

Verification: the full commands/action package passes (130 tests, 0 failures, 0 errors); mvn formatter:format impsort:sort is clean.

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.
• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.

---

Claude Code on behalf of Adriano Machado

[davsclaus]

Good batch of test additions — clean, well-structured, and consistent with the patterns from Batches A and B.

Highlights:

• All 8 new test classes follow the established ActionCommandTestSupport harness correctly
• No Thread.sleep — reuses the Awaitility-based callWithResponse responder
• Proper scope boundaries documented (e.g., CamelRouteStructureActionTest explains why the no-match fallback path is out of scope for unit tests)
• writeMessageHistoryFile helper is well-documented and follows the existing writeStatusFile pattern
• Fixtures are realistic with appropriate JSON fields matching production expectations

Minor (non-blocking): CamelHistoryActionTest.singleTraceLine() and CamelSendActionTest.sentResponse() use System.currentTimeMillis() to populate fixture timestamps — a fixed constant (e.g., 1_700_000_000_000L) would be slightly more deterministic, but since the production code just formats whatever timestamp it receives, this is fine as-is.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.