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.
Currently, you just have to place your stubs in a 'stubs' directory at crate root, something like this:
bash
├── 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.
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.
```toml [package] build = "build.rs"
[build-dependencies]
stubr-build = "0.4.14"
producer-a = "
Then in your build.rs:
rust
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
```rust
fn mytest() { // local bindings with the name of each producer are created isahc::get(producera.uri()).expectstatusok(); isahc::get(producerb.uri()).expectstatus_ok(); } ```
Or without macros
```rust
fn mytest() { let apps = Stubr::appsblocking(&["producer-a", "producer-b"]); let (producera, producerb) = (apps.get(0).unwrap(), apps.get(1).unwrap()); isahc::get(producera.uri()).expectstatusok(); isahc::get(producerb.uri()).expectstatusok(); } ```