This section is very odd, I don't think I've ever seen tests set up that way (but I might be wrong).
Normally, you have:
- a tests submodule to unit-test internal behaviour (gated with cfg(test))
- a top-level `tests` subdirectory, which contains integration tests leveraging the public API of the crate
The dead_code strictures are also unnatural, but I guess the author just didn't call their functions from `main.rs`, and didn't re-expose them either?
Anyway usually in that case you'd just `allow` the warning at the toplevel.
> Add the following three lines to your Cargo.toml and you're good to go: reqwest = { version = "0.11", features = ["json"] } and tokio = { version = "1", features = ["full"] } and serde_json = "1".
FWIW reqwest has a `blocking` submodule, so you don't have to explicitly care about async to use reqwest (though it'll still be pulled as I think reqwest just implements the sync API on top of the async one).
Since the article doesn't actually cover async it seems unnecessary to bring it up.
Incidentally, Rust's async is very similar to Python's semantically, but thanks to the static typing it's also significantly more reliable and easier to use (because the compiler can tell you when you're not using / awaiting a coroutine, whereas python will blithely let you ignore it, and only unhelpfully tell you that you've got unawaited coroutines somewhere at program termination).
dead_code is required because Rust compiles each integration test as a separate crate. This causes spurious warnings to be emitted if you want to share code between tests. See https://github.com/rust-lang/rust/issues/46379
Modules and crates continues to be one of the most confusing aspects of Rust, for me at least.
Here dead code is on the SUT not on the test utilities. In that situation the SUT would normally be either used or pub, here it’s not because the SUT is artificial, library-type code in a binary crate.
You can use `cargo add` to add dependencies, it's part of the standard set: https://doc.rust-lang.org/cargo/commands/cargo-add.html
> Writing tests
This section is very odd, I don't think I've ever seen tests set up that way (but I might be wrong).
Normally, you have:
- a tests submodule to unit-test internal behaviour (gated with cfg(test))
- a top-level `tests` subdirectory, which contains integration tests leveraging the public API of the crate
The dead_code strictures are also unnatural, but I guess the author just didn't call their functions from `main.rs`, and didn't re-expose them either?
Anyway usually in that case you'd just `allow` the warning at the toplevel.
> Add the following three lines to your Cargo.toml and you're good to go: reqwest = { version = "0.11", features = ["json"] } and tokio = { version = "1", features = ["full"] } and serde_json = "1".
FWIW reqwest has a `blocking` submodule, so you don't have to explicitly care about async to use reqwest (though it'll still be pulled as I think reqwest just implements the sync API on top of the async one).
Since the article doesn't actually cover async it seems unnecessary to bring it up.
Incidentally, Rust's async is very similar to Python's semantically, but thanks to the static typing it's also significantly more reliable and easier to use (because the compiler can tell you when you're not using / awaiting a coroutine, whereas python will blithely let you ignore it, and only unhelpfully tell you that you've got unawaited coroutines somewhere at program termination).