Awaitility is a small Java DSL for synchronizing asynchronous operations

Consider providing until version that accepts lambda expression that is able to throw:

Awaitility.await().atMost(...).until(() -> {
...
callThatThrowsException();
...
})

Right now this looks like:

Awaitility.await().atMost(...).until(() -> {
...
try {
    callThatThrowsException();
} catch(Exception e) {
    throw new RuntimeException(e);
}
...
})

I can provide an implementation if you are ok with until() accepting something like ThrowableRunnable.

What do you think about making the dontCatchUncaughtExceptions a setting by default?

I think, sometimes catchs of uncaught exceptions lead to unexpected behaviour in tests,

for example:

@Test
public void testFailed() throws InterruptedException {
    ThreadPoolTaskExecutor taskExecutor = setUpExecutor();
    taskExecutor.execute(new ErrorTestTask());
    ListenableFuture<?> future = taskExecutor.submitListenable(new ErrorTestTask());
    Awaitility.await()
              .atMost(1, TimeUnit.SECONDS)
              .pollInterval(10, TimeUnit.MILLISECONDS)
              .until(future::isDone);
}

@Test
public void testSuccess() throws InterruptedException {
    ThreadPoolTaskExecutor taskExecutor = setUpExecutor();
    taskExecutor.execute(new ErrorTestTask());
    ListenableFuture<?> future = taskExecutor.submitListenable(new ErrorTestTask());
    Thread.sleep(1000);
     Assertions.assertThat(future.isDone()).isTrue();
}

private ThreadPoolTaskExecutor setUpExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setThreadNamePrefix(THREAD_NAME_PREFIX);
    executor.setMaxPoolSize(1);
    executor.afterPropertiesSet();
    return executor;
}

private static class ErrorTestTask implements Runnable {
    @Override
    public void run() {
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        throw new RuntimeException(Thread.currentThread().getName() + " -> Error");
    }
}

When I replaced Thread.sleep on the Awaitility, I got a failed test.

I encountered this problem when I refactored a lot of tests to use the Awaitility instead of the Thread.sleep. It took quite a long time to understand that the problem was in another thread.

Code:

Awaitility.await().until({ "something" })

1.7.0: passes 2.0.0: fails with

java.lang.String cannot be cast to java.lang.Boolean
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
	at org.awaitility.core.CallableCondition$ConditionEvaluationWrapper.eval(CallableCondition.java:100)
	at org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

AwaitilityGroovyBridge used runnable as Callable<Boolean> while AwaitilityExtensionModule uses runnable as Callable.

Implementing AwaitilityTrait does not help, it seems that the extension module takes precedence. You need to change the closure to { "something" != null }.

Release Notes don't mention any breaking changes, so I consider this as a regression.

Also, please update examples from https://github.com/awaitility/awaitility/wiki/Groovy - they use deprecated classes.

In my current project we use a library that heavily depends on thread local variables. We have our own ExecutorService implementation that manages propagation of thread local variables between threads when needed.

When code is executed within await().until() blocks this thread local magic breaks because Awaitility uses its own ExecutorService. It would be nice to allow client code to set custom ExecutorService to enable this type of scenarios.

This is a small program that demonstrates the behavior I'm seeing that appears to be a bug.

Actual behavior: When this runs it exits and prints IllegalArgumentException stack trace like a normal java program. The weird behavior is if you comment out the line .dontCatchUncaughtExceptions(), it will exit with status code 1 and not print the exception.

Expected behavior: I would expect awaitility to not affect exceptions thrown in the same thread and outside its until() {} block.

Version: org.awaitility awaitility 3.1.2

public static void main(final String... args) throws Exception {
        final AtomicInteger count = new AtomicInteger(0);
        await()
                .dontCatchUncaughtExceptions()
                .ignoreExceptionsMatching(instanceOf(IOException.class))
                .atMost(3, TimeUnit.MINUTES)
                .until(() -> {
                    count.incrementAndGet();
                    return count.get() > 3;
                });

        if (true) {
            System.out.println("throwing an exception");
            throw new IllegalArgumentException("broken");
        }
        System.out.println("Already exited so you won't see this");
}

Awaitility already works fine with Kotlin, but there are a few instances where you can't inline calls to until.

It would also be nice to be able to use Kotlin idioms such as:

Awaitility.await().until {
    x > y
}

It would be nice to have a built-in feature that will allow awaiting for some event happening more than once. For example, I'm sending three messages to the queue and expecting that they all three will be received at some point in time.

for (Message message : messages) {
    sendMessageToTheQueue(message);
}

List<Message> messages = await().until(receiveMessage(), hasMyId(), times(3));

...
Callable<Message> receiveMessage();
Matcher<Message> hasMyId();

Awaitility is almost ideal for our purposes with one exception: we'd like to back off exponentially (or perhaps with a Fibonacci sequence) in our polling rather than use a fixed interval.

I may have missed it, but I didn't see a way in the docs or code to provide my own retry policy.

This adds option ignoreExceptions, which treats Exceptions that occur during condition evaluation as non-fatal, evaluating to false. This helped us cover a use case where we did RestAssured statements, which threw exceptions during the period asserts on the path failed, before settling into boolean values.

While I was testing Kafka I end up with some issues around Awaitility. The goal was to test that Kafka topic doesn't contain the new records for a specified time. This is the simplified scratch of my test but it shows the problem. I expect that ConditionTimeoutException doesn't throw in this case. But it does.

public static void main(String[] args) {
        List<String> list = new ArrayList<>();
        await("wait").during(5_000, TimeUnit.MILLISECONDS).atMost(5_000, TimeUnit.MILLISECONDS)
                .pollInterval(100, TimeUnit.MILLISECONDS)
                .until(() -> list, List::isEmpty);
}

I increased the atMost timeout to 5000 + pollInterval -> 5100 but still end up with an exception. On my local machine throwing exception was stoped closed the value of atMost timeout of 5170-5180. Should I keep something in mind? Or may the test isn't correct?

I have a few situations where I don't want certain exceptions to interrupt my wait, but for debugging purposes it's quite valuable to have the information that this exception occured. Therefore it would be nice to be able to register a ExceptionListener (or extend the ConditionEvaluationListener) to handle those exceptions.

Bumps actions/checkout from 2 to 3.1.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps actions/setup-java from 2 to 3.5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hey there!

I'd like to add more flexible and simple way to add global logging for all conditions and logging for single condition.

Global Awaitility settings

from

Awaitility.setDefaultConditionEvaluationListener(new ConditionEvaluationLogger(log::info()));

To

Awaitility.setLogging(log::info);

or for the System.out

Awaitility.setDefaultLogging();

Single Condition settings

from

await()
    .with()
    .conditionEvaluationListener(new ConditionEvaluationLogger(log::info))
    .pollInterval(ONE_HUNDRED_MILLISECONDS)
    .until(logs::size, is(4));

to

await()
    .with()
    .logging(log::info)
    .pollInterval(ONE_HUNDRED_MILLISECONDS)
    .until(logs::size, is(4));

or for the System.out

await()
    .with()
    .logging()
    .pollInterval(ONE_HUNDRED_MILLISECONDS)
    .until(logs::size, is(4));

TODO

• [x] global Awaitility settings
• [x] single Condition settings
• [x] unit tests
• [x] java docs
• [ ] user docs

Bumps maven-jar-plugin from 2.4 to 3.3.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Maybe an esoteric requirement, but I couldn't find an existing nice way anywhere (in or outside Awaitility) to do this. I need to assert in my tests that indeed a method blocks for at least some amount of time.

I imagine an api something like this:

await().atLeast(5 seconds).threadBlocks(() -> somethingThatBlocksForAWhile());

My implementation looks like this:

public class BlockedThreadAsserter {

    AtomicBoolean methodReturned = new AtomicBoolean(false);

    public boolean functionHasCompleted() {
        return methodReturned.get();
    }

    public void assertFunctionBlocks(Runnable functionExpectedToBlock, final Duration blockedForAtLeast) {
        Thread blocked = new Thread(() -> {
            try {
                functionExpectedToBlock.run();
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
            methodReturned.set(true);
        });
        blocked.start();

        await()
                .pollDelay(blockedForAtLeast) // makes sure it is still blocked after 1 second
                .atMost(blockedForAtLeast.plus(Duration.ofSeconds(1)))
                .untilAsserted(
                        () -> Truth.assertWithMessage("Thread should be sleeping/blocked and not have returned")
                                .that(methodReturned.get())
                                .isFalse());
    }

    // method: assert function doesn't block

    // method: assert function unblocks only after 2 seconds - useful for when we can't use a separate thread to check due to locking semantics
    public void assertUnblocksAfter(final Runnable functionExpectedToBlock,
                                    final Duration unblocksAfter) {
        throw new NotImplementedException();
    }
}

usage

var commitBlocks = new BlockedThreadAsserter();
commitBlocks.assertFunctionBlocks(pc::commitOffsetsThatAreReady, ofSeconds(2));

<snip>

//
await().untilAsserted(() -> Truth.assertWithMessage("commit should now have unlocked and returned")
        .that(commitBlocks.functionHasCompleted())
        .isTrue());

Bumps maven-help-plugin from 2.2 to 3.3.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.