-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
Delay mock response #160
Comments
since you're using async code there, try tokio::time::sleep instead - though you'd have to wrap the contents of the closure in |
I've tried to use tokio::time::sleep, but it doesn't look like async can be used in the |
I couldn't figure out the reason for the delay. I'll have a closer look when implemeting |
what works right now is using the sync API: let mut s = mockito::Server::new();
let _m = s.mock("GET", "/").with_body_from_fn(|writer| {
std::thread::sleep(std::time::Duration::from_secs(5));
writer.write_all(b"test")
}).create(); ...but you'd have to change those tests using the sync API to be fully sync. |
I don't think I can actually. This is a pretty simple example, but the tests are using some async components that are actually the ones sending the request to the mock. I have a workaround in place for now, so I guess I'll wait until the async equivalent is in place. Thanks for the help :) |
I'm getting the same exact issue as before:
|
@sr-gi the difference seems quite small (except for the multithreaded scenario), which is probably why I didn't spot it. if that's a problem then I'd recommend again the sync scenario. otherwise you can have a look under the hood yourself, I'd accept a pull request if you can figure out the issue 😸 |
Yeah, the two first scenarios are actually correct, the small difference may come from how I'm actually accounting for the delays. It is the multithreaded case that breaks my tests. I'll try to see if there is a way of implementing a variant of |
I've been using
.with_body_from_fn
to add delays to some of my mock responses as suggested in #64 (comment). e.g:However, I've noticed that when tests are run in parallel as part of a bigger suite, the elapsed time for the delays is bigger than expected. This does not happen if the test is run standalone or if tests are run using
-test-threads=1
.So that poses two questions:
The text was updated successfully, but these errors were encountered: