Very nice, Thomas! I suggest people use this in new tests and also
convert old tests when convenient (if you're in that code or working on
a timing related failure). For failures this approach can be slower but
in the success case it will often speed things up, while also allowing
for extra time if the environment is a bit slow or has a hiccup.
On 7/25/2014 7:22 AM, Thomas Segismont wrote:
Hi everyone,
I was working on timing issues in our tests suite. Those issues often
happen when we have to wait for an async process completion:
* wait for alerts to be fired
* wait for a resource to be discovered
* ... etc
The common answer to that problem was often to raise the value of the
Thread#sleep parameter (sometimes from a few seconds to a few
minutes), thus making the build slower.
I wrote a change in the test-utils module. It's a new method in
AssertUtils:
======
public static void timedAssertion(AssertUtils.BooleanCondition
booleanCondition,
String message,
long maxWait,
TimeUnit maxWaitUnit,
long step,
TimeUnit stepUnit)
throws InterruptedException
Asserts a condition evaluates to true before a timeout is reached.
Parameters:
booleanCondition - the condition to evaluare
message - the message to show if this assertion fails
maxWait - the maximum amount of time to wait before the condition
evaluates to true
maxWaitUnit - the time unit for maxWait
step - the amount of time to make the executing thread sleep between
condition evaluations
stepUnit - the time unit for step
Throws:
AssertionError - if the conditions does not evaluate to true before
the timeout is reached
InterruptedException - if the current thread is interrupted while waiting
======
I've just used it to fix an issue in the server itest suite. I hope it
will be helpful for everyone.
Regards,
Thomas
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel