Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doing something after a Mock responded #85

Open
johannescpk opened this issue Jan 7, 2022 · 3 comments
Open

Doing something after a Mock responded #85

johannescpk opened this issue Jan 7, 2022 · 3 comments

Comments

@johannescpk
Copy link

Sometimes it'd be useful to have some logic run after a mock finished responding (so the client doing the request received the response). Currently this doesn't seem to be possible. I've tried to work on it but was blocked by hyperium/hyper#2731. So any suggestions how this could be handled differently would be appreciated.

@LukeMathWalker
Copy link
Owner

What kind of logic are you trying to run?

@johannescpk
Copy link
Author

In this case the same as #84 (comment), tho to make the test work correctly it'd require to run after the mock caller got the response.

@onelson
Copy link

onelson commented Feb 25, 2024

I ran into this recently and added a loop to poll the received requests from the mock server in my tests. Something like:

    let mut interval = tokio::time::interval(std::time::Duration::from_millis(10));
    let mut retries = 50;
    loop {
        interval.tick().await;
        retries -= 1;
        let reqs = mock_server.received_requests().await.unwrap_or_default();
        if !reqs.is_empty() || retries <= 0 {
            break;
        }
    }
    mock_server.verify().await;

It would be nicer (for me specifically) if there were some sort of a stream or channel interface where I could either block while waiting on the received request in a cancel-safe way, or poll the next one (returning immediately if there are no new requests buffered in the stream).

For context, in my case the request being made to the mock is a downstream side-effect of things initiated in the test. There's a separate worker thread that sends the request indirectly. This means my test can't just wait for the response to know the whole flow completed; I have to spy on the mock server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants