Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Similar to #116 but slightly different execution. (code is not how I want it to be yet, and the tests don't yet pass. this is purely to demonstrate the extra complexity this adds).
The original
is_satisfied
API was designed around the idea we could poll in a backoff loop for a mock to have received its expected calls. The compelling use case here is triggering an async action through a message queue, and expecting a HTTP request eventually.Instead of using polls with a retry loop, we could instead utilise the tools Rust gives us with async futures. These are already poll loops, but with reactive management rather than passive timers. This seems more correct to me.
I would also have liked to make
satisfied
take a timeout duration by default, but given this library is async runtime agnostic, I'd rather not break that hereBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.