stubr-build

One of the key benefit of relying upon json files for stubbing your web applications is that they are both portable and language agnostic.
This crates aims at introducing a 'producer-driven' way of testing your applications: a producer (which exposes the API) publishes its mocks ; consumer(s) app(s) pull them and can use those stubs in their tests, configuring their http clients to hit them.

as a producer

Currently, you just have to place your stubs in a 'stubs' directory at crate root, something like this:

├── src
├── stubs
    ├── get.json
    └── post.json
└── Cargo.toml

If you have some include or exclude in your Cargo.toml make sure it does not involve the stubs directory.

as a consumer

In your Cargo.toml use stubr-build in your build-dependencies and also add your producer apps. You also need to invoke it in a build.rs file.

[package]
build = "build.rs"

[build-dependencies]
stubr-build = "0.4.11"
producer-a = "<version>"
producer-b = "<version>"

Then in your build.rs:

fn main() { stubr_build::stubr_consumer() }

In order to extract stubs (invoke the build script), cargo build has to be invoked. So think about executing it before tests in your CI or locally.

To mount those stubs in a server you can then use a macro

#[test]
#[stubr::apps("producer-a", "producer-b")]
fn my_test() {
    // local bindings with the name of each producer are created
    isahc::get(producer_a.uri()).expect_status_ok();
    isahc::get(producer_b.uri()).expect_status_ok();
}

Or without macros

#[test]
fn my_test() {
    let apps = Stubr::apps_blocking(&["producer-a", "producer-b"]);
    let (producer_a, producer_b) = (apps.get(0).unwrap(), apps.get(1).unwrap());
    isahc::get(producer_a.uri()).expect_status_ok();
    isahc::get(producer_b.uri()).expect_status_ok();
}