shashank created CAMEL-25821:
--------------------------------
Summary: camel-test-dst - more pitfalls for agents writing worlds
in the guide
Key: CAMEL-25821
URL: https://issues.apache.org/jira/browse/CAMEL-25821
Project: Camel
Issue Type: Improvement
Components: camel-test
Reporter: shashank
Assignee: shashank
The guide "Writing a fake world" of camel-test-dst (CAMEL-25738,
{{test-dst.adoc}}) lists the pitfalls seen when agents wrote the first nine
worlds. Writing worlds for IMAP, JMS, NATS JetStream and Azure Service Bus with
the merged harness ran into more of them. Each one cost a round of false
failures or a run that never ended, and each fits in one or two sentences of
the guide.
*Change* (docs only, the module page and its catalog copy):
* "No end to the run" says what to do with a consumer task that never returns
(a pull loop): it sits above the test thread on the one stack, so
{{dst.runFor}} / {{dst.runUntil}} in the test body cannot return while it
loops. The phases of the run become scheduled tasks, and the run ends by having
the fake close the subscription, then {{runUntil(closed)}}.
* New pitfalls: a fake that answers at once with nothing makes a tight loop in
which virtual time does not move (give it a round-trip latency); a
{{java.lang.reflect.Proxy}} fake turns an undeclared checked exception into
{{UndeclaredThrowableException}} (do what the library does); the fake must
model what the client library does with objects of an earlier connection, not
only the server; each kind of operator stop needs its own excuse record; a
synchronous consumer over {{DstCamel.asyncStep}} needs
{{DefaultAsyncProcessorAwaitManager}} in {{alsoRewrite}}, and the asynchronous
exchanges in flight must finish before {{dropPending()}}.
* Running the tests: a component whose tests depend on a {{camel-test-infra-*}}
module needs it in {{-pl}} when it is not in the local repository.
* Limits: a world in a module with parallel tests (camel-sjms, camel-jms) can
be run alone with {{-Dcamel.surefire.parallel=false}} but cannot be committed
there (the harness refuses to start under parallel JUnit, as before); locks do
not exclude on the one stack, so races between two lock-holding code paths
cannot be explored.
Each statement was checked against the harness on main ({{Dst}},
{{DstExtension}}, {{DstInstrumentation}}, {{DstCamel}}).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
