LukeMathWalker / wiremock-rs

HTTP mocking to test Rust applications.
Apache License 2.0
620 stars 70 forks source link

Simulate connect delay #19

Open mre opened 4 years ago

mre commented 4 years ago

Hey,

thanks for the crate.

I'm building a link checker and I need a way to simulate a connect delay. Here's a little snippet to show what I tried:

    #[tokio::test]
    async fn test_timeout() {
        let mock_server = MockServer::start().await;
        let delay = Duration::from_secs(30);
        let template = ResponseTemplate::new(200).set_delay(delay.clone());
        Mock::given(method("GET"))
            .respond_with(template)
            .mount(&mock_server)
            .await;

        let res = get_checker(false, HeaderMap::new())
            .check(&Url::parse(&mock_server.uri()).unwrap())
            .await;
        assert!(matches!(res, Status::Timeout));
    }

get_checker is just a wrapper around reqwest.

This didn't work. It's obvious, in hindsight, because I was mixing up the response delay with a connect delay. Any way I could test that right now? Maybe there could be another parameter set_connect_delay for that?

LukeMathWalker commented 4 years ago

Hey @mre!

Right now I don't believe there is a way for you to simulate a connection delay: I would imagine that being a set_connect_delay method on the MockServer itself more than on a specific Mock/ResponseTemplate as set_delay is right now. To be honest, I am not even sure how to simulate it but I'd be keen to support it - any idea you have on the topic that I might go off and research a bit?

mre commented 4 years ago

Hey, thanks for the feedback. You're right, the MockServer might not be the right place. I have to say working with the ResponseTemplate was really fun, so if you can I'd add it there. I didn't find much, but this disussion on Tokio might be a starting point.

pawroman commented 3 years ago

This is a very useful feature and I'd like to help here.

I have done some digging into this, and I think we could simulate a connect delay quite easily. Basically the idea is to delay (e.g. by sleeping) each of the accept calls on the server socket. This would most likely be perceived as a "connect delay" by most HTTP clients, since the TCP connection would not be established for some time.

I would have to confirm this by poking around with a toy HTTP server. Tools like wget and curl let you specify the connect timeout, so the hypothesis can be confirmed experimentally.

LukeMathWalker commented 3 years ago

I was under the impression that adding a delay on accept calls would have not tricked HTTP clients, but, alas, I have not verified it. Would you like to give it a go @pawroman and let us know the outcome?