Custom messages or method calls on success and timeout

[Ádám Zovits]

Hi!

I've been looking in the wiki and the javadoc, but can't seem to find a solution for my problem.

I'd like to have Awaitility wait for a certain event and log message A if the event has happened before the timeout or log message B if the timeout was reached without the event happening. (Or call methods A or B in the more generic case)

The current solution looks like this:

try {

    Awaitility.given().pollInterval(100, TimeUnit.MILLISECONDS).await().atMost(10000, TimeUnit.MILLISECONDS).until(() -> someEventHasHappened());

    LOG.log("A");

} catch (ConditionTimeoutException cte) {

    LOG.log("B");

}

But this is a bit too long and cumbersome for repeated use.

Ideally the solution would look something like this:

Awaitility.given().pollInterval(100, TimeUnit.MILLISECONDS).await().atMost(10000, TimeUnit.MILLISECONDS).until(() -> someEventHasHappened()).thenLog("A).orElseLog("B");

Of course, that is way too specific, so more realistically maybe something like this:

Awaitility.given().pollInterval(100, TimeUnit.MILLISECONDS).await().atMost(10000, TimeUnit.MILLISECONDS).until(() -> someEventHasHappened()).then(logMessageA).else(logMessageB);

Where the logMessageX variables would be Callables, of which the correct one is called upon exiting normally or timeouting.

Or is there maybe any other mechanism, pattern or hack to distinguish between exits due to the condition being fulfilled and exits due to the timeout being reached that does not involve a try-catch(ConditionTimeoutException) block and so can be written on one-two lines? For example:

Awaitility.given().pollInterval(100, TimeUnit.MILLISECONDS).await("someName").atMost(10000, TimeUnit.MILLISECONDS).until(() -> someEventHasHappened());

Awaitility.completedBeforeTimeout("someName") ? LOG.log("A") : LOG.log("B");

Thank you in advance!

[Johan Haleby]

Hi, 

Couldn't use just write your own function that wraps the try/catch stuff? I'm hesitant to add something to the library to solve this and it would also break the API since "until" currently returns the result of the condition.

/Johan

--
You received this message because you are subscribed to the Google Groups "Awaitility" group.
To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ádám Zovits]

Hi!

It would be possible, but we'd like to avoid this. It would require so many parameters to configure all aspects (poll interval, wait time, matcher, onsuccess, onfailure) some of which are sometimes multiple lines themselves, that the result would arguably even harder to read and comprehend than the try-catch block above. It would also lose the attractive DSL syntax of Awaitility that we already grew fond of.

I certainly respect your decision to not to change the API, in fact I only wanted to inquiry if such a function is already implemented in some way, for I thought this would be quite a common use case. So thank you for confirming that it was not an oversight from my part, we'll keep on using the try-catch blocks.

Adam

To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+...@googlegroups.com.

[Ronald Brindl]

Hi, I just stumbled across this thread, because I am looking for something similar.

I am just in the process of replacing our home-brewn legacy "wait-framework" with awaitility. 

In our old framework we had a log output when something started to wait, when it finished successfully and when it ended. 

Using logback, we collected all those logs, enriched with other metadata like testname, machine name, etc. to graylog.

So we were able to do extensive analysis of how our test lab behaved with regards to timing.

If a test fails sporadically with a timeout, you could see that in the cases it was successful it only just made it within the timeout, so we had good reason to increase the timeout.

Or we would see that some things only time out on windows, but not on linux.

I would like to be able to do something like:

await("foobar")

   .atMost(1, MINUTES)

   .onStart((condition)->logger.info("Start waiting for {} for {}ms", condition.getAlias(), condition.getRemainingTimeInMS()))

   .onSuccess((condition)->logger.info("Successfully waited for {} for {}ms", condition.getAlias(), condition.getElapsedTimeInMS()))

   .onTimeout((condition)->logger.info("Timed out waiting for {} after {}ms", condition.getAlias(), condition.getElapsedTimeInMS()))

   .until(() -> foobarIsTrue());

Is there any way to extend the framework in such a way, e.g. by providing a custom factory method instead of Awaitility.await(...) and wrapping the condition to support the methods I mentioned.

Does this make sense?

Regards,

Ron.

[Johan Haleby]

Maybe you could use a ConditionEvaluationListener?

To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+unsubscribe@googlegroups.com.

[Ronald Brindl]

I tried now with ConditionEvaluationListener, but there are some problems I have with it:

1.) It is called only after the first execution of a condition, so I cannot really log something like "started waiting", or do some other kind of things I would like to do before first evaluation.

2.) It is not called at all in case of a timeout. 

Regards,

Ron.

[Johan Haleby]

Perhaps we should add that to the ConditionEvaluationListener? I.e. add a hook that's executed before the condition is executed and also invoke it for a timeout.

To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+unsubscribe@googlegroups.com.

[Ronald Brindl]

That would solve the problems.

Would you then add a method to `org.awaitility.core.ConditionEvaluationListener`? E.g. `beforeEvaluation` or something like that. It would also need a parameter similar to "EvaluatedCondition", so I can see the alias, timeout values etc. Probably just the `ConditionSettings`?

BTW. this would also solve a problem I was about to post an issue for: Customizing thread names (pollThread did no work because of https://github.com/awaitility/awaitility/issues/101).

For the timeout it would be enough to just call `conditionEvaluated` after a timeout. By checking `EvaluatedCondition#isSatisfied` and `EvaluatedCondition#getRemainingTimeInMS` I can find out if it is a timeout or not.

Regards, 

Ron.

[Johan Haleby]

Could you please add an issue for this so that it's not forgotten?

To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+unsubscribe@googlegroups.com.

[Ronald Brindl]

created https://github.com/awaitility/awaitility/issues/102

[Johan Haleby]

thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to awaitility+unsubscribe@googlegroups.com.