HTTP mocking for Rust!


HTTP mocking for Rust!

Get it on

Documentation is available at

Before upgrading, make sure to check out the changelog.

Contribution Guidelines

  1. Check the existing issues and pull requests.
  2. One commit is one feature - consider squashing.
  3. Format code with cargo fmt.
  4. :shipit:



Run tests:

cargo test

...or run tests using a different toolchain:

rustup run --install 1.42.0 cargo test

...or run tests while disabling the default features (e.g. the colors):

cargo test --no-default-features

Code style

Mockito uses rustfmt as a general code style.

Install rustfmt:

rustup component add rustfmt

Format code:

cargo fmt

Some editors might provide a plugin to format your Rust code automatically.


Mockito uses clippy and it should be run always on the minimum supported Rust version, in order to ensure backwards compatibility.

Install clippy:

rustup component add clippy-preview

Run the linter on the minimum supported Rust version:

rustup run --install 1.42.0 cargo clippy --lib --tests --all-features -- -D clippy::complexity



cargo publish


Install rust nightly:

rustup install nightly

Run benchmarks:

rustup run nightly cargo bench

Logo courtesy to 👌

  • dynamic ports

    dynamic ports

    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?

    opened by jupp0r 18
  • Test suite fails randomly (due to a possible race condition?)

    Test suite fails randomly (due to a possible race condition?)

    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: 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:

    % cargo test -- --nocapture
        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/
    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
    ...but received 0
    ', /Users/kyrylo/.cargo/registry/src/
    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
    ...but received 0
    ', /Users/kyrylo/.cargo/registry/src/
    test it_attaches_params ... FAILED
    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!

    work in progress 
    opened by kyrylo 14
  • Invalid instruction

    Invalid instruction


    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/
    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/
       1:     0x55cb79e451b8 - std::sys_common::backtrace::_print::h0a244112d948cad7
                                   at src/libstd/sys_common/
       2:     0x55cb79e48252 - std::panicking::default_hook::{{closure}}::hb199339b212075e6
                                   at src/libstd/sys_common/
                                   at src/libstd/
       3:     0x55cb79e47fc4 - std::panicking::default_hook::h0f5d79d3aeb5cebe
                                   at src/libstd/
       4:     0x55cb79e48960 - std::panicking::rust_panic_with_hook::hebcac80ec729c98d
                                   at src/libstd/
       5:     0x55cb79e484e1 - std::panicking::continue_panic_fmt::h83729debd9444082
                                   at src/libstd/
       6:     0x55cb79e483c5 - rust_begin_unwind
                                   at src/libstd/
       7:     0x55cb79e65b2c - core::panicking::panic_fmt::hc3bc1d4b55face00
                                   at src/libcore/
       8:     0x55cb79637365 - core::result::unwrap_failed::h5f7b56502d8e7619
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/
       9:     0x55cb796354d5 - <core::result::Result<T, E>>::unwrap::h30bf3792771bba7b
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/
      10:     0x55cb7962e058 - mockito::Matcher::matches_value::h6b88e003f3f163fd
                                   at /home/otavio/.cargo/registry/src/
      11:     0x55cb7962daf5 - mockito::server::<impl mockito::Mock>::body_matches::hfa524c6f2077ff58
                                   at /home/otavio/.cargo/registry/src/
      12:     0x55cb7962db71 - mockito::server::<impl core::cmp::PartialEq<mockito::request::Request> for &'a mut mockito::Mock>::eq::hfe00a18b02575a17
                                   at /home/otavio/.cargo/registry/src/
      13:     0x55cb7962d173 - core::cmp::impls::<impl core::cmp::PartialEq<&'b B> for &'a A>::eq::h860d9b6762530b92
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/
      14:     0x55cb7963b24a - mockito::server::handle_match_mock::{{closure}}::h43cd654f00ccbb66
                                   at /home/otavio/.cargo/registry/src/
      15:     0x55cb79660850 - core::iter::traits::DoubleEndedIterator::rfind::{{closure}}::h2d6c58c85061bda0
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/
      16:     0x55cb79625204 - <core::slice::IterMut<'a, T> as core::iter::traits::DoubleEndedIterator>::try_rfold::ha97d61d3f6ae9f27
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/slice/
      17:     0x55cb79625897 - core::iter::traits::DoubleEndedIterator::rfind::hd806c94572edc275
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/
      18:     0x55cb796615dd - <core::iter::Rev<I> as core::iter::iterator::Iterator>::find::h1c9b2002948692d9
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libcore/iter/
      19:     0x55cb7963adea - mockito::server::handle_match_mock::h9ab341bc060c8b8b
                                   at /home/otavio/.cargo/registry/src/
      20:     0x55cb7963ac0a - mockito::server::handle_request::h1be4e3f2b46e1cf4
                                   at /home/otavio/.cargo/registry/src/
      21:     0x55cb7963a513 - mockito::server::try_start::{{closure}}::h19e1783d6319ac32
                                   at /home/otavio/.cargo/registry/src/
      22:     0x55cb7964cada - std::sys_common::backtrace::__rust_begin_short_backtrace::h360cdcc582893ddf
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/sys_common/
      23:     0x55cb7965c67d - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::hc57d6fa74e4f46d3
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/thread/
      24:     0x55cb7965b3fd - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h7de1a177b1a95085
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/
      25:     0x55cb7965c844 - std::panicking::try::do_call::h1c0328330a706679
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/
      26:     0x55cb79e52449 - __rust_maybe_catch_panic
                                   at src/libpanic_unwind/
      27:     0x55cb7965c765 - std::panicking::try::h1d902e6b2af3dd1f
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/
      28:     0x55cb7965bbcd - std::panic::catch_unwind::haf4142276f498d7e
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/
      29:     0x55cb7965c47d - std::thread::Builder::spawn_unchecked::{{closure}}::ha27e096332f07b6c
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/libstd/thread/
      30:     0x55cb79660e99 - <F as alloc::boxed::FnBox<A>>::call_box::h1270d75b0ae800e1
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/liballoc/
      31:     0x55cb79e5180d - std::sys::unix::thread::Thread::new::thread_start::hd9992a1ec79303ca
                                   at /rustc/2fadb0a16c8737a45746e95df9138912590ed8ad/src/liballoc/
                                   at src/libstd/sys_common/
                                   at src/libstd/sys/unix/
      32:     0x7f046884ea9c - start_thread
      33:     0x7f0468762b22 - clone
      34:                0x0 - <unknown>
    opened by otavio 10
  • Match binary body

    Match binary body

    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();
    1. 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();
    1. 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.

    opened by torrefatto 9
  • Uppercase the incoming request method

    Uppercase the incoming request method

    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.

    opened by mikrostew 9
  • basic regex support

    basic regex support

    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.

    opened by estin 9
  • Multivalued headers

    Multivalued headers

    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.

    opened by kornelski 7
  • Tests hang on window

    Tests hang on window


    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

    I tracked the issue down to, 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

    opened by afonso360 7
  • Mock with latency?

    Mock with latency?

    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

    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!

    opened by nbigaouette-eai 6
  • lib: keep compatibility with older toolchains

    lib: keep compatibility with older toolchains

    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).

    opened by lucab 6
  • values with spaces from serde_urlencoded don't match Matcher::UrlEncoded

    values with spaces from serde_urlencoded don't match Matcher::UrlEncoded

    trivial example to reproduce:

    use serde::Serialize;
    use serde_urlencoded;
    use mockito;
    struct Form {
        pub key: String,
    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()))
            // encoded by serde_urlencoded to "value+with+spaces!"
            .form(&Form { key: "value with spaces!".into() })
            .unwrap(); // <- This panics because mockito responds 501 Not Implemented
    opened by cakekindel 5
  • Add support for HTTP/2

    Add support for HTTP/2

    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!

    opened by doxblek 0
  • matchbody with PartialJson no match causes serde::json::error::Error - EOFWhileParsingValue

    matchbody with PartialJson no match causes serde::json::error::Error - EOFWhileParsingValue

    • 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.


    async fn test_demonstate_mockito_json_error_eof() {
        let client = SomeApiClient::new(&mockito::server_url());
        let mock = mock("POST", "/")
                "someFlag": true,
            // send_request forwards the body json
        let result = client
                "someFlag": false,
            .expect("Received some unexpected error"); // panic here with EOF error
        mock.assert() // never reached
    opened by lewcinho 0
  • Always fail with reqwest blocking

    Always fail with reqwest blocking

    use core::time::Duration;
    use reqwest::header::USER_AGENT;
    let _m = mock("GET", "/hello")
        .with_header("content-type", "text/plain")
        .with_body("Hello World")
    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")
    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]`
    opened by kinosang 0
  • Request with HTTP 1.0 hangs

    Request with HTTP 1.0 hangs

    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();
    mod tests {
        use super::*;
        use mockito::mock;
        use mockito::server_url;
        async fn test_with_reqwest() {
            let _m = mock("HEAD", "/")
                .with_body(b"some bytes")
            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);


    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.

    fn test_propagate_protocol_to_response_head() {
        let _mock = mock("HEAD", "/").create();
        let stream = request_stream("1.0", "HEAD /", "", "");
        let (status_line, _, _) = parse_stream(stream, true);
        assert_eq!("HTTP/1.0 200 OK\r\n", status_line);
    opened by JamesSharkey 1
  • Mocks can receive requests from previous tests

    Mocks can receive requests from previous tests

    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")
        ... // add header and body

    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.

    opened by Matthias247 2
  • Run `assert` on Drop

    Run `assert` on Drop

    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

    opened by jyn514 3
  • 0.31.1(Dec 5, 2022)

  • 0.31.0(Feb 26, 2022)

  • 0.30.0(Mar 18, 2021)

  • 0.29.0(Jan 24, 2021)

  • 0.28.0(Nov 4, 2020)

  • 0.27.0(Jul 25, 2020)

  • 0.26.0(Jun 28, 2020)

  • 0.25.3(Jun 28, 2020)

  • 0.25.2(May 30, 2020)

  • 0.25.1(Apr 8, 2020)

    • When creating multiple mocks that match the same request, the last defined mock should be the one matched forever, once the all other mocks have reached their expected amount of hits. See and
    Source code(tar.gz)
    Source code(zip)
  • 0.25.0(Apr 5, 2020)

    • You can provide different mocks (and especially mock responses) for subsequent requests to the same endpoint. See and
    • The 501 Mock Not Implemented response now comes with a content-length: 0 header, to prevent some clients from hanging.

    Thanks to @xneomac

    Source code(tar.gz)
    Source code(zip)
  • 0.24.0(Mar 15, 2020)

  • 0.23.3(Feb 21, 2020)

  • 0.23.2(Feb 19, 2020)

  • 0.23.1(Feb 5, 2020)

  • 0.23.0(Jan 30, 2020)

    • [Breaking] Increased the minimum supported Rust toolchain to 1.35.0.
    • Introduced the Mock#expect_at_least and Mock#expect_at_most functions to be used together with Mock#assert.
    • Bumped the percent-encoding dependency.
    • Introduced cargo fmt formatting as part of CI.

    Thanks to @kornelski @xneomac @thomasetter

    Source code(tar.gz)
    Source code(zip)
  • 0.22.0(Nov 11, 2019)

  • 0.21.0(Sep 25, 2019)

    • Introduced a feature flag color (enabled by default), that controls whether the output is coloured and, more importantly, whether the colored crate is required.

    Thanks to @repi

    Source code(tar.gz)
    Source code(zip)
  • 0.20.0(Jul 29, 2019)

  • 0.19.0(Jul 20, 2019)

  • 0.18.0(Jul 11, 2019)

    • [Breaking] The minimum supported Rust version was increased to 1.32, after upgrading the rand crate dependency to 0.7.0.
    • Introduced Matcher::AllOf, which can be used to check a set of matchers in conjunction. It works in a similar way to the existing Matcher::AnyOf.
    • Introduced Matcher::UrlEncoded to match key/value pairs in URL-encoded strings.
    • Introduced Mock#match_query to be able to match the URL query part distinctly from the path. The function supports all known matchers but works best with Matcher::UrlEncoded. The old behaviour of matching the query as part of the path argument in a mock call has been preserved, but using Mock#match_query has the effect of overriding that.

    :balloon: :balloon: :balloon:

    Source code(tar.gz)
    Source code(zip)
  • 0.17.1(Apr 28, 2019)

  • 0.17.0(Mar 25, 2019)

  • 0.16.0(Feb 18, 2019)

    • Support HTTP/1.0 and working without Content-Length.
    • Allow overriding the Content-Length response header and skipping the response body entirely in the particular case of HEAD requests.

    Thanks to @loyd

    Source code(tar.gz)
    Source code(zip)
  • 0.15.1(Feb 4, 2019)

  • 0.15.0(Jan 1, 2019)

    • [Breaking] The mock sever will get a dynamically assigned port, though it will try port 1234 first. You will need to change the way you set the server URL - from mockito::SERVER_URL or mockito::SERVER_ADDRESS to mockito::server_url() or mockito::server_address().

    Thanks to @kornelski

    Source code(tar.gz)
    Source code(zip)
  • 0.14.1(Dec 21, 2018)

    • Refactored the server checks - thanks to @kornelski
    • Debug mode: use the log crate instead of the old custom logger - thanks to @kornelski
    • Keep compatibility with older toolchains - thanks to @lucab
    • Introduce clippy - thanks to @macisamuele
    Source code(tar.gz)
    Source code(zip)
  • 0.14.0(Nov 18, 2018)

    ~~This is the release candidate for the 1.0.0 :tada: ~~

    • [Breaking] Fully deprecated Matcher::JSON, in favour of Matcher::Json.
    • Replace http-muncher with httparse. This fixed the issues regarding the failing Windows tests. See and
    • Updated dependencies.

    Thanks to @sterlingjensen, @otavio, @galaxie and @mikrostew

    Source code(tar.gz)
    Source code(zip)
  • 0.13.0(Sep 17, 2018)

    • Introduced the Matcher::AnyOf variant, which takes a vector of matchers as argument.
    • The Mock::with_body and Mock::with_body_from_file functions now support binary content.
    • Multi-valued headers (e.g. the Via header) are checked over all values. The previous implementation was looking only for the first found header value.
    • Changed the response reason phrase for non-matching requests from 501 Not Implemented to 501 Mock Not Found.
    • Changed the response reason phrase for unparseable requests from 422 Unprocessable Entity to 422 Mock Error.

    Thanks to @kornelski

    Source code(tar.gz)
    Source code(zip)
  • 0.12.0(Jun 27, 2018)

    • Introduced a coloured diff, comparing the expected request with the last unmatched request whenver the Mock::assert() method fails. Closes
    • Removed the limitation on the test function name, but also rendered it impossible to create mocks from threads.
    Source code(tar.gz)
    Source code(zip)
Florin Lipan
Florin Lipan
Struct mocking library for Rust

faux   A library to create mocks out of structs. faux allows you to mock the methods of structs for testing without complicating or polluting your cod

Andres 322 Dec 20, 2022
Drill is an HTTP load testing application written in Rust inspired by Ansible syntax

Drill is an HTTP load testing application written in Rust inspired by Ansible syntax

Ferran Basora 1.5k Jan 1, 2023
Verdun is a HTTP stress-test/benchmark tool written in Rust.

Verdun is a HTTP stress-test/benchmark tool written in Rust. ?? It supports testing a single URL, loading multiples URLs from a file or automatically navigating a website (auto discovery)

Alex Hortopan 2 Feb 23, 2022
hb is an endpoint focused HTTP load testing / benchmark tool.

hb hb is an endpoint focused HTTP load testing / benchmark tool. Description The goal of hb is to provide a simple, robust tool to apply load against

Mark Pritchard 2 Aug 23, 2022
A structure-aware HTTP fuzzing library

?? FeroxFuzz ?? A structure-aware HTTP fuzzing library ?? Another ferox? why? ?? Chill, it's not another command-line tool, this one's a library! ?? M

epi 141 Dec 27, 2022
Handle some load with Rust, while learning Rust

lila-http Take some of the HTTP load away from lila. WIP! Arena tournaments Clients connected to a tournament page request new data about the tourname

Lichess 22 Jan 2, 2023
Testing Framework for Rust

Polish Polish is Test-Driven Development done right Getting Started Installing the Package The package is kept up-to-date with all the major

Fadi Hanna Al-Kass 49 Dec 18, 2022
🐇 Fuzzing Rust code with American Fuzzy Lop Fuzzing Rust code with AFLplusplus What is it? Fuzz testing is a software testing technique used to find security and stability issues by provi

Rust Fuzzing Authority 1.3k Jan 5, 2023
Travis CI and AppVeyor template to test your Rust crate on 5 architectures and publish binary releases of it for Linux, macOS and Windows

trust Travis CI and AppVeyor template to test your Rust crate on 5 architectures and publish binary releases of it for Linux, macOS and Windows Featur

Jorge Aparicio 1.2k Dec 30, 2022
A library for generating fake data in Rust.

Fake A Rust library for generating fake data. Installation Default (rand is required): [dependencies] fake = "2.4" rand = "0.8" If you want to use #[d

cksac 552 Dec 25, 2022
Benchmarks for rust serialization frameworks

Rust serialization benchmark The goal of these benchmarks is to provide thorough and complete benchmarks for various rust serialization frameworks. Th

David Koloski 187 Jan 4, 2023
Playwright is a rust library to automate Chromium, Firefox and WebKit built on top of Node.js library.

?? Playwright for Rust Playwright is a rust library to automate Chromium, Firefox and WebKit built on top of Node.js library. Installation [dependenci

octaltree 132 Jan 6, 2023
ArchTest is a rule based architecture testing tool for rust

ArchTest is a rule based architecture testing tool. It applies static analyses on the specified rust project to extract use relationships.

Tom Dymel 7 Sep 26, 2021
Advanced Fuzzing Library - Slot your Fuzzer together in Rust! Scales across cores and machines. For Windows, Android, MacOS, Linux, no_std, ...

LibAFL, the fuzzer library. Advanced Fuzzing Library - Slot your own fuzzers together and extend their features using Rust. LibAFL is written and main

Advanced Fuzzing League ++ 1.2k Dec 29, 2022
Structure-aware, in-process, coverage-guided, evolutionary fuzzing engine for Rust functions.

fuzzcheck Fuzzcheck is a structure-aware, in-process, coverage-guided, evolutionary fuzzing engine for Rust functions. Given a function test: (T) -> b

Loïc Lecrenier 394 Dec 20, 2022
A fuzzer framework built in Rust

lain This crate provides functionality one may find useful while developing a fuzzer. A recent nightly Rust build is required for the specialization f

Microsoft 469 Dec 9, 2022
A fast Rust-based safe and thead-friendly grammar-based fuzz generator

Intro fzero is a grammar-based fuzzer that generates a Rust application inspired by the paper "Building Fast Fuzzers" by Rahul Gopinath and Andreas Ze

null 203 Nov 9, 2022
How-to: Sanitize your Rust code!

rust-san How-to: Sanitize your Rust code! Intro How to use the sanitizers? Examples AddressSanitizer Out of bounds access Use after free LeakSanitizer

Jorge Aparicio 359 Dec 22, 2022
Automated property based testing for Rust (with shrinking).

quickcheck QuickCheck is a way to do property based testing using randomly generated input. This crate comes with the ability to randomly generate and

Andrew Gallant 2k Jan 2, 2023