atMost to have poll count options about awaitility HOT 6 OPEN

That sounds like a good idea. Not sure how easy it would be to implement though. I think we need a new concept that unifies atMostTimes and atMost. I.e. a StopCondition or something similar. I.e. there can be a TimingBasedStopCondition (atMost) and a CountBasedStopCondition (atMostTimes) that are both StopCondition's. If so you ought to be able to a supply custom StopCondition to Awaitility similar to how to can define custom poll intervals. It would also be cool if StopCondition's can be composable..

from awaitility.

Agree with your thought on the abstraction - let me see if i can spare some cycles and get you a pull request.

from awaitility.

That would be great!

from awaitility.

I have done intial refactoring to change duration to time based stop condition. This is draft to get all the test passing. I will relook at cleaning this change up before i proceed with Count based stop condition. Meanwhile if you have any thoughts on the commit- please let me know.

from awaitility.

There has been some changes internally as part of PR 45. There's now a WaitConstraint interface that (currently) have two implementations. Perhaps this could be refactored to also support this use case? I.e. instead of having methods such as getMaxWaitTime in the interface it could have a method such as isExceeded(pollCount, currentTime) and the implementations could react to this. This method should probably be invoked from the ConditionAwaiter class since it has this kind of information.

from awaitility.

Did anything happen further on this request, is it still being considered?

from awaitility.