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.

Reply via email to