awaitility / awaitility Goto Github PK
View Code? Open in Web Editor NEWAwaitility is a small Java DSL for synchronizing asynchronous operations
License: Apache License 2.0
Awaitility is a small Java DSL for synchronizing asynchronous operations
License: Apache License 2.0
fyi, the current release of Hamcrest is, org.hamcrest:java-hamcrest:2.0.0.0
(note the coordinate changed). There isn't much that has visibly changed, but helps avoid needing to add exclusions for those who've upgraded.
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
}
Apologies if I'm coming at this from the wrong angle but is there any support (or direction of how i should do this) for running some code after the condition has been evaluated to true e.g. my current code is as follows
await().atMost(5, SECONDS).until(() -> someList.size(), is(equalTo(1))
is there any support for something like
await().atMost(5, SECONDS).until(() -> someList.size(), is(equalTo(1)).andThen(() -> assertThat(someList.get(0), is(equalTo("hello")))
so I know there is definitely 1 message, now I can do more assertions on the contents of the list
We're using Awaitility in integration tests and it would be great if we could supply a more useful failure message. For example instead of "expected not null but was within 10 seconds." we'd like to see "transfer order not set within 10 seconds" or something like that.
What about a new release of awaitility?
The last release was half a year ago and I like to use the new groovy extension: 1c1d0b2
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
.
Classes implementing the AwaitilitySupport
trait are failing when using scala 2.12.x with the following message
failed: java.lang.NoSuchMethodError: org.awaitility.scala.AwaitilitySupport.$init$(Lorg/awaitility
/scala/AwaitilitySupport;)V
The same code works fine with scala 2.11.8
What steps will reproduce the problem?
1. Write an assertion that checks objects/list of objects which do not have a
toString() method implemented
2. Have the assertion condition fail with a timeout
What is the expected output? What do you see instead?
The original mismatch description is not preserved in the message of the
ConditionTimeoutException, the second part of the message ("but was ...") just
contains the return value of toString()
What version of the product are you using? On what operating system?
awaitility 1.6.3 on Ubuntu 14.04 LTS x64, Java 1.8.0_40
Please provide any additional information below.
The code to display a more descriptive message is actually present in the code
but commented out:
https://github.com/jayway/awaitility/blob/4e9a036ef9bada9cba9219875e0be5e8fc4c83
98/awaitility/src/main/java/com/jayway/awaitility/core/AbstractHamcrestCondition
.java#L63-L64
The reason we do not have toString() on our objects is that in most cases it
would output a lengthy list of parameters that would just flood the console and
make everything unreadable.
Judging by the code there is no way for me to enable more descriptive messages.
Could you please consider changing the message to include more descriptive
messages or include an option for enabling them?
Original issue reported on code.google.com by [email protected]
on 18 Mar 2015 at 11:00
(This is verified on 1.7.0, I have not tested 2.0.0, but at least the documentation has not changed)
The following three test cases have different behaviour.
The first one rethrows the exception immediately. The second one swallows the exception, waits for 10 seconds, then rethrows it. The third one succeeds.
I would expect that at least the latter two cases would succeed, since handling of AssertionFailedErrors is clearly already special, and arguably also the first one should succeed, since the API documentation of until(Callable<Boolean>)
does not say anything about passing through exceptions, and some exceptions are already handled in special manner.
public class AwaitTest {
@Test
public void testUntilCallableBoolean_RuntimeException() {
final AtomicInteger counter = new AtomicInteger(0);
await().atMost(10, TimeUnit.SECONDS).until(() -> {
if (counter.get() < 2) {
counter.incrementAndGet();
throw new RuntimeException("Not yet");
} else {
return true;
}
});
}
@Test
public void testUntilCallableBoolean_AssertionFailedError() {
final AtomicInteger counter = new AtomicInteger(0);
await().atMost(10, TimeUnit.SECONDS).until(() -> {
counter.incrementAndGet();
assertTrue(counter.get() >= 2);
return true;
});
}
@Test
public void testUntilRunnable() {
final AtomicInteger counter = new AtomicInteger(0);
await().atMost(10, TimeUnit.SECONDS).until(() -> {
counter.incrementAndGet();
assertTrue(counter.get() >= 2);
});
}
}
Why does the MethodCallRecorder use static fields to record the lastTarget?
I frequently get Method call not recorded error message. Could it be connected to the MethodCallRecorder static fields and parallel test execution?
java.lang.IllegalStateException: No method call has been recorded. Perhaps the method was final?
at com.jayway.awaitility.core.MethodCallRecorder.getLastTarget(MethodCallRecorder.java:68)
at com.jayway.awaitility.core.ConditionFactory.untilCall(ConditionFactory.java:363)
at com.hazelcast.concurrent.lock.ConditionBasicTest.testSignalWithMultipleWaiters(ConditionBasicTest.java:372)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)
Hi,
Sometimes we need to wait for something if it gonna happen, but it's fine if it's not.
"Wait until a condition is true or timeout is reached" semantic, where reaching a timeout is not an exceptional case.
Example:
We have an application that writes logs. These logs are flushed asynchronously and with non-deterministic delay. In our unit test, we want to check the state of the application log, which could be empty and it could be fine. So, we need to wait for 5 seconds, abort waiting if the log became non-empty, or just silently continue execution after this 5 seconds if the log is still empty because it's a normal case.
Now we need to deal with ConditionTimeoutException which will be thrown if the condition is not met after the waiting period, which is ugly and makes the code messy.
Proposal:
Add .silent() method to awaitility building chain which disables throwing the exception.
Optional:
Add result value to .until() method to make it possible to understand if the condition has been met during waiting without one more explicit check
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.
I was wondering if we can have an atMostTimes method with poll count as option.
await().atMostTimes(10).with().pollInterval(10,TimeUnit.MILLISECONDS).until(....)
My intention is try at most 10 times to obtain the desired result with until
.
Please let me know your thoughts or if i have missed this already existing option.
Awaitility depends on cglib (which is quite large and makes osgi integration harder) only because of the "to" method that creates class proxies. Perhaps we should extract support for creating cglib proxies into a legacy library, awaitility-legacy. Note that "to" could still be retained for non-class proxy purposes that only uses the standard java Proxy class.
according to Changelog 2.0.0: "Awaitility now requires Java 6"
but "Long.compare(getValueInMS(), other.getValueInMS());" which is used in "Duration.java", is since from java 1.7
I'm getting the following message:
java.util.concurrent.TimeoutException:
com.test.AwaitilityTest.recievedMessageCount Callable expected a value greater
than or equal to <7000> but was <7901> within 1 seconds.
at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:82)
at com.jayway.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:50)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:560)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:412)
What steps will reproduce the problem?
1. awaitility 1.3.3, junit 4.8.1, hamcrest-core 1.1, hamcrest-library
2. Using a Netty Client Server app to send messages asynchronously. Checking
Server for messages received.
3. with().pollInterval(500,
MILLISECONDS).and().timeout(1,SECONDS).await().until(recievedMessageCount(channe
lAddress), greaterThan(7000));
I have tried Matchers greaterThan and greaterThanOrEqualTo but both fail
intermitentantly even if the value IS greater than the value expected.
Original issue reported on code.google.com by desmond.kirrane
on 16 Jan 2012 at 6:34
In the below fragment only the 1st from the two await().untilAsserted(...) calls is executed:
Awaitility.pollInSameThread();
await().untilAsserted(() -> {
System.out.println("checking stuff 1...");
assertThat("1234").isEqualTo("1234");
});
await().untilAsserted(() -> {
System.out.println("checking stuff 2..."); // This is never reached
assertThat("1234").isEqualTo("1234");
});
The problem seems to be that the SameThreadExecutor
instance which is created upon pollInSameThread
mutates after the 1st execution and cannot be reused after that.
It might be nice if there was .untilNotify(Object obj) that waited until notify was invoked on the obj argument.
The reason for this is that I have a legacy application that is already significantly relying upon wait/notify, and there are various usages of wait could be simplified to something like await().atMost(ONE_SECOND).untilNotify(myObj)
without forcing me to refactor all of the existing synchronization logic.
await().until(fakeServer::recordedRequestUrls, hasItem(endsWith("/api/v2/11")));
gives:
org.awaitility.core.ConditionTimeoutException: Lambda expression in SomeTest that uses SomeTest: expected a collection containing a string ending with "/api/v2/11" but within 10 seconds.
note double space after "but". This happens when there's no elements in fakeServer::recordedRequestUrls
, if there are elements in fakeServer::recordedRequestUrls
(but they don't match with the expectation) then the error message is fine.
It would be very nice to be able to intercept the lifecycle of a condition each time before it is evaluated. This hook could be used to refresh the state before checking the condition.
I'm thinking of the following syntax:
await("data).atMost(ONE_MINUTE).repeat(this::refreshData).until(this::checkData);
In this example the "refreshData" method fetches some data from a remote data store and saves it in a class field. The "checkData" checks the field if it matches a certain condition.
Currently I have to combine both operations into the "checkData" method. Introducing that new concept would make my code more modular and reusable.
Thanks!
Add untilNot( () -> checkIfCrashedError() ) feature
Idea is to wait x sec and throw exception if condition is meet.
Example:
publish(message)
awaits().atMost(5, SECONDS).untilNot( () -> errorQueue.size()==0 )
Awesome project!
Just my 0.02
For example it would be cool to be able to do:
await().between(ONE_SECOND, FIVE_SECONDS).until(..)
Perhaps it's more clear to do:
await().atLeast(ONE_SECOND).and().atMost(FIVE_SECONDS).until(..)
Right now it throws an exception
Hi,
Great project, been using it for a while now and very pleased :)
I wanted to know if there is any way to limit the number of used threads so Awaitilty will block until a new thread is available.
Went over the code and saw that AbstractHamcrestCondition creates a new thread each time, if I'd like to introduce a ThreadPool or executor would this be the right place?
E.g.
await().until(repo::isNotEmpty, repo::hasAnyX);
Original issue reported on code.google.com by [email protected]
on 22 May 2014 at 11:54
With awaitility-groovy module on a classpath it is not possible to use unitl(Runnable)
with Groovy Closure, e.g.
await().until({ assertThat(foo).isEqualTo(bar) })
//or
await().until({ wiremock.verifyThat(postRequestedFor(urlEqualTo("...")) }
Where verifyThat
throws AssertError if condition is not fulfilled (the same as AssertJ). This is caused by the fact that AwaitilityExtensionModule treats all Clusures
as Runnable
:
if (runnable instanceof Callable)
self.until(runnable as Callable)
else
self.until(new AssertionCondition(runnable, self.generateConditionSettings()))
In general it is good, because Groovy by default would use until(Runnable)
instead of until(Callable)
. Nevertheless the use case mentioned above is broken.
Unfortunately I don't see a good way to fix it. All ideas I have are far from being perfect:
new Runnable() { void run() { ... } }
explicitly.AwaitilityGroovySupplier
to mark Closure
s which should be treated as Runnable
and use it in AwaitilityExtensionModule
until(Runnable)
JavaDoc to give people a chance to get know about that.Maybe you will have some other ideas.
One more thing. Probably not much people use aforementioned path as AssertJ with Groovy is usually not needed and Wiremock is also only for specific scenarios. In addition people using Spock can as an alternative to Awaitility use PollingCondition
from Spock. In that case maybe the 4rd point would be enough?
I was wondering how I would go about adding the downloaded dependencies and jars to eclipse
Methods for ignoring exceptions should have Class<Throwable>
arguments
This test passes:
@Test(expected = IllegalStateException.class)
public void rethrows() {
Awaitility.await()
.atMost(1, TimeUnit.SECONDS)
.until(
new Callable<Boolean>() {
@Override
public Boolean call() throws Exception {
throw new IllegalStateException("Hello");
}
}
);
}
If you replace IllegalStateException
with AssertionError
or any other kind of error, it will fail.
This will also allow for waiting for void methods.
Original issue reported on code.google.com by [email protected]
on 12 Apr 2011 at 7:48
Having the complete stacktrace of the last assertion failure would make things easier.
Currently I cannot use something like
await()...(() -> {
...
assertNotNull(var1);
assertNotNull(var2);
}
because the ConditionTimeoutException is the same for both assertions.
Thanks
Lars
Hi, the links at the bottom of the documentation page https://github.com/awaitility/awaitility/wiki/Usage has a few links that no longer have a valid endpoint.
Thank you for Awaitiliy. We use it extensively!
What steps will reproduce the problem?
1. Add the line "compile 'com.jayway.awaitility:awaitility-groovy:1.6.3'" to
dependencies in an Android build.gradle.
2. Attempt to build the project.
What is the expected output? What do you see instead?
Expected nothing to happen as awaitility is not yet referenced from the tests.
Instead I get a build error:
Error:Execution failed for task ':app:dexDebug'.
> com.android.ide.common.internal.LoggedErrorException: Failed to run command:
/home/chris/Android/Sdk/build-tools/21.1.2/dx --dex --no-optimize --output /home/chris/AndroidStudioProjects/androidmdt/app/build/intermediates/dex/debug --input-list=/home/chris/AndroidStudioProjects/androidmdt/app/build/intermediates/tmp/dex/debug/inputList.txt
Error Code:
2
Output:
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536
at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:502)
at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:277)
at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:491)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:168)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:189)
at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:454)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:303)
at com.android.dx.command.dexer.Main.run(Main.java:246)
at com.android.dx.command.dexer.Main.main(Main.java:215)
at com.android.dx.command.Main.main(Main.java:106)
The build error goes away when I remove the dependency on awaitility.
I also get repeated warnings when awaitility is a dependency:
Warning:Ignoring InnerClasses attribute for an anonymous inner class
(net.sf.cglib.util.StringSwitcher$Generator$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
What version of the product are you using? On what operating system?
awaitility 1.6.3
android studio 1.2
java 1.8.0_40-b25 amd64
ubuntu 14.04 x86_64
Original issue reported on code.google.com by [email protected]
on 14 May 2015 at 12:58
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.
I think it'd be useful to be able to do sth like:
Awaitility.await().atMost(ONE_SECOND).metFor(ONE_SECOND).until(...)
Meaning that if the condition is met within one second,
then we continue to check it with the same interval for another second
to make sure it still gives the same result.
That'd be useful for scenarios where you're checking for example
number of received messages, to make sure nothing more then expected was actually received.
What steps will reproduce the problem?
1. Run awaitly for unit tests in android. Allow the callable to timeout.
What is the expected output? What do you see instead?
It should fail gracefully. Instead a NoClassDefFoundError exception is thrown
because android doesn't have the java.lang.management.ManagementFactory class.
What version of the product are you using? On what operating system?
1.6.3
Please provide any additional information below.
java.lang.NoClassDefFoundError: Failed resolution of:
Ljava/lang/management/ManagementFactory;
at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:98)
at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:78)
at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:25)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:590)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:582)
Ultimately, awaitly still works with android tests, it just fails erroneously
when timing out.
Original issue reported on code.google.com by [email protected]
on 3 Feb 2015 at 6:50
CGLib can be specially troublesome when you have different versions of the library that are being pulled by different libraries.
It seems it's a common practice to shade this library (see Spring, Mockito) in order to avoid these problems.
Can you consider this?
Also, the version being used is almost 3 years old, it would be good to upgrade it (latest at this moment is 3.2.4)
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.
I would like to use awaitility in pax exam for doing OSGi testing. This requires the jar to be a bundle though. I can provide the needed changes if you are interested.
This simple test case, leaves a thread running:
@test
public void checkThreadsLeft() throws Exception {
await("asdf").until(() -> true);
}
Stack trace of the thread that has been left:
Thread[Thread-0,5,main]
at java.lang.Thread.sleep(Native Method)
at org.awaitility.core.ConditionAwaiter$1.run(ConditionAwaiter.java:163)
at java.lang.Thread.run(Thread.java:745)
Is there a way to terminate this thread?
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.
For use with pollDelay
In
org.awaitility.core.ConditionAwaiter#pollSchedulingThread
a thread is created that doesn't have a name.
I think it could be helpful if that thread had a name containing "awaitility"
In the page "https://github.com/awaitility/awaitility/wiki/Usage", under the section Links and code examples, the links mentioned are broken.
Eg.
The link mentioned is:
http://github.org/awaitility/blob/master/awaitility/src/test/java/org/awaitility/UsingAtomicTest.java
but it should be:
https://github.com/awaitility/awaitility/blob/master/awaitility/src/test/java/org/awaitility/UsingAtomicTest.java
Kindly update. Unfortunately we can't create Pull request for Github Wiki, or else I would have fixed it myself.
Thanks for a wonderful library.
What steps will reproduce the problem?
1.Awaitility.await().until(requestStatus(instanceService, requestId1),
equalTo(RequestStatus.STARTED));
2.
3.
What is the expected output? What do you see instead?
requestStatus function is called just once instead of multiple times during 10
seconds.
What version of the product are you using? On what operating system?
The bug is in versions 1.6.3 and 1.6.2,
version 1.6.1 works ok.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 9 Feb 2015 at 9:58
Sometimes, and I repeat sometimes I get the following error while running my junit tests on Android
I'm using version 1.6.5 but 1.6.3 used to have the same issue.
java.lang.NoClassDefFoundError: Failed resolution of: Ljava/lang/management/ManagementFactory;
at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:100)
at com.jayway.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:87)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:713)
at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:530)
at com.myapp.test.test.MainTests.testLogin(MainTests.java:488)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1853)
Caused by: java.lang.ClassNotFoundException: Didn't find class "java.lang.management.ManagementFactory" on path: DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/com.myapp.test.test-2/base.apk", zip file "/data/app/com.myapp.test-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
... 17 more
Suppressed: java.lang.ClassNotFoundException: java.lang.management.ManagementFactory
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
... 18 more
Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack available
We are using Awaitility inside our tests and some test are throwing
AssertionError from inside of Callable supplier. As the result we got
ConditionTimeoutException without any cause and it looked like Awaitility just
stopped calling our supplier for no reason. I think the problem is that
AssertionError is not an Exception, but Awaitility catches only Exceptions in
ConditionAwaiter line 57
What is the expected output? What do you see instead?
We expect to see stack trace of the AssertionError or it being re-thrown.
Instead we see ConditionTimeoutException which doesn't show the real cause
What version of the product are you using? On what operating system?
1.6.3 on any operating system
Original issue reported on code.google.com by [email protected]
on 16 Jun 2015 at 12:32
Hi!
I would like to know if there's a possibility to set an initial delay for polling.
I need to test an async feature that, when invoked, clear some data and then do some stuff.
In that scenario will be useful to set a initial delay before the assertion, otherwise the test will pass because the assertion will verify before the feature clear the data.
now we setted a thread sleep before using awaitility.
Could be an interesting enhancement?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.