HTTP mocking for Rust!

Using a static port for mockito makes integration tests brittle for a number of reasons:

• port 1234 might be taken by an outside process
• another user on the same machine might also run mockito tests
• another test binary might be running for the same user
• multiple threads

Mockito could bind to port 0, which makes the OS choose a free port to bind on, and then let the test know which port was chosen. This would also enable parallel test execution which each test having their own mockito instance on their own port.

Thoughts, ideas?

Hi, thanks for the library, it's fun and easy to use!

I suspect I hit a bug with mockito 0.11.0. I have a small test suite of 3 tests and 50% of the time it fails. It may be a race condition, however it's just a wild guess since I'm very new to mockito and I don't know how exactly it works.

I am using the following code: https://github.com/kyrylo/airbrake-rust/tree/reboot You can clone the repo (make sure to checkout the reboot branch, commit sha is a6514530305c537a029af838a86cdef72fbeb948) and run tests yourself. Here's a sample output:

    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running target/debug/deps/airbrake-9afc2687bc83f1a7

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/airbrake-ac572b687ba1c60e

running 3 tests
thread 'it_notifies_airbrake' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `2`:
Expected 1 request(s) to:

POST /api/v3/projects/113743/notices
content-type: application/json

...but received 2

', /Users/kyrylo/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.11.0/src/lib.rs:677:44
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'it_attaches_a_backtrace' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`:
Expected 1 request(s) to:

POST /api/v3/projects/113743/notices
"backtrace":\[\{"line":\d+,"file":".+","function":".+".*\}\]

...but received 0

', /Users/kyrylo/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.11.0/src/lib.rs:677:44
test it_notifies_airbrake ... FAILED
test it_attaches_a_backtrace ... FAILED
thread 'it_attaches_params' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `0`:
Expected 1 request(s) to:

POST /api/v3/projects/113743/notices
"params":\{"banana":\{"String":"tasty"\},"mango":\{"Int32":42\}\}

...but received 0

', /Users/kyrylo/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.11.0/src/lib.rs:677:44
test it_attaches_params ... FAILED

failures:

failures:
    it_attaches_a_backtrace
    it_attaches_params
    it_notifies_airbrake

test result: FAILED. 0 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test airbrake'

As you can see one of the tests outputs ...but received 2, however I make only one HTTP request there. The call is in the same thread and it's synchronous (at least I can state that my library's code doesn't do anything clever in this department).

It's worth mentioning that if I comment the last test, then the other 2 tests pass consistently. Perhaps, the test is flawed? I can't see how it could be the case, but if it is, my apologies for the false report.

I would appreciate some assistance here. Thanks!

Hello,

Using 0.14 and 0.15 I get following backtrace:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:997:5
stack backtrace:
test states::download::test::download_has_transition_callback_trait ... ok
   0:     0x55cb79e4a483 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::he292500cb069592b
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:     0x55cb79e451b8 - std::sys_common::backtrace::_print::h0a244112d948cad7
                               at src/libstd/sys_common/backtrace.rs:70
   2:     0x55cb79e48252 - std::panicking::default_hook::{{closure}}::hb199339b212075e6
                               at src/libstd/sys_common/backtrace.rs:58
                               at src/libstd/panicking.rs:200
   3:     0x55cb79e47fc4 - std::panicking::default_hook::h0f5d79d3aeb5cebe
                               at src/libstd/panicking.rs:215
   4:     0x55cb79e48960 - std::panicking::rust_panic_with_hook::hebcac80ec729c98d
                               at src/libstd/panicking.rs:478
   5:     0x55cb79e484e1 - std::panicking::continue_panic_fmt::h83729debd9444082
                               at src/libstd/panicking.rs:385
   6:     0x55cb79e483c5 - rust_begin_unwind
                               at src/libstd/panicking.rs:312
   7:     0x55cb79e65b2c - core::panicking::panic_fmt::hc3bc1d4b55face00
                               at src/libcore/panicking.rs:85
   8:     0x55cb79637365 - core::result::unwrap_failed::h5f7b56502d8e7619
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/macros.rs:16
   9:     0x55cb796354d5 - <core::result::Result<T, E>>::unwrap::h30bf3792771bba7b
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/result.rs:798
  10:     0x55cb7962e058 - mockito::Matcher::matches_value::h6b88e003f3f163fd
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/lib.rs:542
  11:     0x55cb7962daf5 - mockito::server::<impl mockito::Mock>::body_matches::hfa524c6f2077ff58
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:25
  12:     0x55cb7962db71 - mockito::server::<impl core::cmp::PartialEq<mockito::request::Request> for &'a mut mockito::Mock>::eq::hfe00a18b02575a17
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:34
  13:     0x55cb7962d173 - core::cmp::impls::<impl core::cmp::PartialEq<&'b B> for &'a A>::eq::h860d9b6762530b92
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/cmp.rs:1003
  14:     0x55cb7963b24a - mockito::server::handle_match_mock::{{closure}}::h43cd654f00ccbb66
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:134
  15:     0x55cb79660850 - core::iter::traits::DoubleEndedIterator::rfind::{{closure}}::h2d6c58c85061bda0
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/traits.rs:635
  16:     0x55cb79625204 - <core::slice::IterMut<'a, T> as core::iter::traits::DoubleEndedIterator>::try_rfold::ha97d61d3f6ae9f27
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/slice/mod.rs:2988
  17:     0x55cb79625897 - core::iter::traits::DoubleEndedIterator::rfind::hd806c94572edc275
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/traits.rs:634
  18:     0x55cb796615dd - <core::iter::Rev<I> as core::iter::iterator::Iterator>::find::h1c9b2002948692d9
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/mod.rs:441
  19:     0x55cb7963adea - mockito::server::handle_match_mock::h9ab341bc060c8b8b
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:134
  20:     0x55cb7963ac0a - mockito::server::handle_request::h1be4e3f2b46e1cf4
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:126
  21:     0x55cb7963a513 - mockito::server::try_start::{{closure}}::h19e1783d6319ac32
                               at /home/otavio/.cargo/registry/src/github.com-1ecc6299db9ec823/mockito-0.15.0/src/server.rs:110
  22:     0x55cb7964cada - std::sys_common::backtrace::__rust_begin_short_backtrace::h360cdcc582893ddf
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/sys_common/backtrace.rs:135
  23:     0x55cb7965c67d - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::hc57d6fa74e4f46d3
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/thread/mod.rs:469
  24:     0x55cb7965b3fd - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h7de1a177b1a95085
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/panic.rs:309
  25:     0x55cb7965c844 - std::panicking::try::do_call::h1c0328330a706679
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/panicking.rs:297
  26:     0x55cb79e52449 - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:92
  27:     0x55cb7965c765 - std::panicking::try::h1d902e6b2af3dd1f
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/panicking.rs:276
  28:     0x55cb7965bbcd - std::panic::catch_unwind::haf4142276f498d7e
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/panic.rs:388
  29:     0x55cb7965c47d - std::thread::Builder::spawn_unchecked::{{closure}}::ha27e096332f07b6c
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/thread/mod.rs:468
  30:     0x55cb79660e99 - <F as alloc::boxed::FnBox<A>>::call_box::h1270d75b0ae800e1
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/liballoc/boxed.rs:734
  31:     0x55cb79e5180d - std::sys::unix::thread::Thread::new::thread_start::hd9992a1ec79303ca
                               at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/liballoc/boxed.rs:744
                               at src/libstd/sys_common/thread.rs:14
                               at src/libstd/sys/unix/thread.rs:81
  32:     0x7f046884ea9c - start_thread
  33:     0x7f0468762b22 - clone
  34:                0x0 - <unknown>

Hi! As discussed here, this PR introduces the possibility to create a mock that matches the exact bytes of a binary payload. We managed not to change the existing API, introducing a new Matcher variant: Matcher::Binary(BinaryBody). There are now three ways to instantiate a mock that matches with this new Matcher:

1. passing a mutable reference to a File (open in read mode)

let mut file = std::fs::File::open("path/to/file")?;
let _m = mock("POST", "/").with_body(&mut file).create();

2. passing a Path (this panics in case of failure to read the file content from the path)

let path = std::path::Path::new("path/to/file");
let _m = mock("POST", "/").with_body(path).create();

3. directly passing a binary payload (i.e. a Vec<u8>)

 let content: Vec<u8> = vec![01, 02, 03, 04];
 let _m = mock("POST", "/").with_body(content).create();

All these three ways have the associated functions implemented by BinaryBody.

When running tests using mockito in win-64, incoming requests frequently parse as <unknown> for some reason. To allow our tests to run and pass in win-64, we would like to be able to match <unknown>, but that is not currently possible because the mocked method is converted to uppercase (in Mock::new()).

This PR converts the incoming request to uppercase, so that <unknown> --> <UNKNOWN>, and we can match against it.

Hi! I want a regex support to mock URL path. This is my vision how to add it. I`m newbie in rust.

Regex used by default for all paths. This is a breaking change... And mock("/ab") will match /abcd.

Sorry for my poor English.

The Via header supports multiple values only as separate headers, so to test it, it's necessary to support multiple values per header.

At this point matching with PartialEq was getting too wild, so I've just changed it to a regular method.

Hi,

When I tried to test this library on windows it seems to hang and use 100% cpu time. The hang can be reproduced on Appveyor

https://ci.appveyor.com/project/afonso360/mockito

I tracked the issue down to server.rs:143, when executing server.handle() it seems to hang.

The newer versions of hyper (git) don't hang on windows, would it be possible to upgrade? The hyper api has changed slightly so it wouldn't be a matter of just changing Cargo.toml

I can probably try to submit a pull request if you want me to

I'm mocking an API that returns a json with content saying if a previous query is running or completed. So I have to poll that API until the initial query is complete. For example:

• From 0 to X ms, GET on /status should return {"status": "starting"}
• From X to Y ms, GET on /status should return {"status": "running"}
• From Y ms and updward, GET on /status should return {"status": "complete"}

I want to test my exponential backoff until completion.

I'm not sure how to do this with mockito right now. Since all requests will be on the same route with the same information (only the return data will be different) I cannot create them all beforehand; how would mockito known which mock to use if they are all identical?

Issue #31 asked for something similar and a suggestion was to use threads to create the mocks. An Arc<Barrier>> can easily be used to synchronize threads (instead of a loop as suggested in #31).

I tried spawning a thread to create and destroy the mocks with the different behavior at the proper timing but got a deadlock. The lock happens at https://github.com/lipanski/mockito/blob/459049a780c49e8837c77cba047b76d5606b322e/src/lib.rs#L774

I also tried to put my client performing the GET in its thread instead and creating the mocks in the "main" test thread but this does not work since reqwest/tokio is not Send.

For now I'm kind of stucked... Any suggestion? Thanks!

This adds a compatibility use statement so that mockito can be successfully built on slightly older toolchains, and adds a travis check for that (arbitrary minimum version: 1.29.0).

trivial example to reproduce:

use serde::Serialize;
use serde_urlencoded;
use mockito;

#[derive(Serialize)]
struct Form {
    pub key: String,
}

#[test]
pub fn bug_demo() {
    let _mock = mockito::mock("POST", "/")
        // mockito expects this to be "value%20with%20spaces!"
       .match_body(mockito::Matcher::UrlEncoded("key".into(), "value with spaces!".into()))
       .create();
    
    reqwest::blocking::Client::new()
        .post(&mockito::server_url())
        // encoded by serde_urlencoded to "value+with+spaces!"
        .form(&Form { key: "value with spaces!".into() })
        .send()
        .unwrap()
        .error_for_status()
        .unwrap(); // <- This panics because mockito responds 501 Not Implemented
}

I ran into the situation where I had to mock an HTTP/2-only-Server. In the application I consumed the server using reqwest. I set reqwest to HTTP/2 only by this:

let client = ClientBuilder::new().http2_prior_knowledge().build()?;

When using mockito, in contrast to the actual server, my unit test hang up (async unit test via tokio). Once I conditionally set reqwest to HTTP/2-only (using #[cfg(test)]), mockito worked as expected.

So it seams mockito is currently not supporting HTTP/2 – also I could not find any related options.

While I was able to find a workaround (that does not even has runtime overhead), it was still preferable to have that feature included.

Thank you!

• Rust version: 1.58.1
• Mockito version: 0.30.0

When using mockito's matchbody method to match requests, when a request is received that is not a good match, a serde::json::error::Error is thrown. This makes troubleshooting the test case difficult, as information on which requests the mock did receive are not exposed at any point.

Example:

#[async_std::test]
async fn test_demonstate_mockito_json_error_eof() {
    let client = SomeApiClient::new(&mockito::server_url());

    let mock = mock("POST", "/")
        .match_body(Matcher::PartialJson(json!({
            "someFlag": true,
        })))
        .with_status(200);

        // send_request forwards the body json
    let result = client
        .send_request(json!({
            "someFlag": false,
        }))
        .await
        .expect("Received some unexpected error"); // panic here with EOF error

    mock.assert() // never reached
}

use core::time::Duration;
use reqwest::header::USER_AGENT;

let _m = mock("GET", "/hello")
    .with_status(200)
    .with_header("content-type", "text/plain")
    .with_body("Hello World")
    .create();

let host = mockito::server_url();

let timeout = Duration::from_millis(3_000);

let client = reqwest::blocking::Client::new();

let req = client
    .get(format!("{}/hello", host))
    .header(USER_AGENT, "ParamiLinker/1.0")
    .timeout(timeout);

let res = req.send().unwrap();

assert_eq!(res.bytes().unwrap().to_vec(), b"Hello World".to_vec());

fail to assert or got 503 error

left: `[]`,
right: `[72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100]`

Hello, I'm testing a client that makes a HTTP 1.0 request. When making the HTTP 1.0 request to mockito it hangs.

use reqwest::{Client, Version, Response};

async fn request_with_version(url: &str, version: Version) -> reqwest::Result<Response> {
    let client = Client::new();
    client.head(url).version(version).send().await
}

#[cfg(test)]
mod tests {
    use super::*;
    use mockito::mock;
    use mockito::server_url;

    #[tokio::test]
    async fn test_with_reqwest() {
        let _m = mock("HEAD", "/")
            .with_body(b"some bytes")
            .create();

        let response = request_with_version(&server_url(), Version::HTTP_11).await.unwrap();
        println!("{:?}", response);

        // Request below never returns
        let response = request_with_version(&server_url(), Version::HTTP_10).await.unwrap();
        println!("{:?}", response);
    }
}

Dependencies:

[dependencies]
mockito = "0.30.0"
reqwest = "0.11.4"
tokio = { version = "1.0.2", features = ["macros"] }

I cloned the mockito repo and added the test below which passed.

#[test]
fn test_propagate_protocol_to_response_head() {
    let _mock = mock("HEAD", "/").create();
 
    let stream = request_stream("1.0", "HEAD /", "", "");
    stream.shutdown(Shutdown::Write).unwrap();
 
    let (status_line, _, _) = parse_stream(stream, true);
    assert_eq!("HTTP/1.0 200 OK\r\n", status_line);
}

I observed an issue where one of my tests using this library failed sporadically with

Expected 2 request(s) to: GET /path ...but received 3

The mock in this test is set up using:

let m = mock("GET", "/path")
    .with_status(500)
    ... // add header and body
    .create()
    .expect(2);

and the client trying to use the mock in this test definitely performs only 2 requests.

After adding a variety of additional logs and a custom header per test, I noticed that the mock received and processed a request from a previous test. That incremented the request count and lead the test to fail.

My understanding is that this connection attempt from the previous test lead to a socket with associated data still sitting in the backlog, and that isn't immediately cleared even if one test closes the listener socket. So the next listener which is bound to the same port ( 1234) will accept that connection and read the data.

The mutex which attempts to isolate test cases against each other doesn't help here. Adding some wait time after each test does, but slows things down even further.

I tried modifying mockito to always bind to :0 and let the OS choose a free port. However it still picked the same for all tests and run into the issue.

So the main thing to make this more reliable besides avoiding expectation around the number of requests seems the following: When the mock is created, accept() all connections which are pending on the socket and drop them before returning to the user. However it seems like there is no try_accept() method on the synchronous listener available.

Right now, any user of the API has to remember to call Mock::assert at the end of each and every test. If they forget, the mock doesn't actually test anything. It would be nice for this to be called automatically without the user having to remember.

Originally reported by @jyn514 in https://github.com/deadlinks/cargo-deadlinks/pull/94#discussion_r523027941