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 here
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
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_satisfiedAPI 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
satisfiedtake 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.