This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new c27a6b9d2c31 Document MockEndpoint timed assertions in AGENTS.md
(#24496)
c27a6b9d2c31 is described below
commit c27a6b9d2c31093612f1cfc23d48f53815de11bb
Author: Guillaume Nodet <[email protected]>
AuthorDate: Thu Jul 9 10:56:48 2026 +0200
Document MockEndpoint timed assertions in AGENTS.md (#24496)
* Document MockEndpoint timed assertions as preferred over Awaitility for
mock-based waits
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* Add note that assertIsSatisfied(context) already waits 10s by default
Co-Authored-By: Claude Opus 4.6 <[email protected]>
* Add explicit rule: do not wrap MockEndpoint.assertIsSatisfied with
Awaitility
Co-Authored-By: Claude Opus 4.6 <[email protected]>
---------
Co-authored-by: Claude Opus 4.6 <[email protected]>
---
AGENTS.md | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/AGENTS.md b/AGENTS.md
index b790b00131a4..30cc545d8f1c 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -163,10 +163,44 @@ await().atMost(20, TimeUnit.SECONDS)
.untilAsserted(() -> assertEquals(1, context.getRoutes().size()));
```
+**MockEndpoint tests — prefer built-in timed assertions:**
+
+When the wait condition is "mock expectations are met", use `MockEndpoint`'s
native timed
+assertion instead of wrapping with Awaitility. It is latch-based (more
efficient than polling)
+and requires no external dependency:
+
+```java
+// Preferred — native, latch-based, returns as soon as expectations are met:
+MockEndpoint.assertIsSatisfied(context, 10, TimeUnit.SECONDS);
+
+// Also available on a single endpoint:
+mock.setResultWaitTime(TimeUnit.SECONDS.toMillis(10));
+mock.assertIsSatisfied();
+
+// DO NOT wrap MockEndpoint assertions with Awaitility — it polls a mechanism
that already waits:
+// await().atMost(10, TimeUnit.SECONDS).untilAsserted(() ->
MockEndpoint.assertIsSatisfied(context));
+```
+
+Note: `MockEndpoint.assertIsSatisfied(context)` (no timeout argument) already
waits up to
+10 seconds internally — `waitForCompleteLatch` defaults to 10 000 ms when
`resultWaitTime`
+is not set. The timed overload is only needed when you want a **different**
timeout.
+
+Use Awaitility only when waiting on a condition that `MockEndpoint` cannot
express natively,
+such as waiting for a specific received count mid-test before performing the
next action:
+
+```java
+// Awaitility IS appropriate here — no MockEndpoint API for "wait until N
received" without asserting:
+await().atMost(10, TimeUnit.SECONDS).until(() -> mock.getReceivedCounter() >=
2);
+```
+
**Rules:**
- New test code MUST NOT introduce `Thread.sleep()` calls.
-- When modifying existing test code that contains `Thread.sleep()`, migrate it
to Awaitility.
+- When modifying existing test code that contains `Thread.sleep()`, migrate it
to
+ `MockEndpoint`'s timed assertions (for mock-based waits) or Awaitility (for
other conditions).
+- Do NOT wrap `MockEndpoint.assertIsSatisfied()` with Awaitility — it already
waits internally
+ via a `CountDownLatch`. Wrapping it with `untilAsserted` adds polling on top
of a mechanism
+ that already blocks, which is redundant and less efficient.
- Always set an explicit `atMost` timeout to avoid hanging builds.
- Use `untilAsserted` or `until` with a clear predicate — do not replace a
sleep with a
busy-wait loop.