How can integration tests execute a different workspace crate's binary?

yaro3 days ago

Within a multi-crate workspace, how can a crate's integration tests require and run another crate's exectuable target, rather than its library target?

Here's the workspace structure:

workspace/
├── rillmere_probe/
│   └── tests/check.rs
└── rillmere_exec/
    ├── src/lib.rs
    └── src/main.rs

The rillmere_probe crate lists rillmere_exec as a dev-dependency. Its tests also need to launch rillmere_exec's binary. Previously this worked fine. However, the build-layout-v2 change in rust-nightly rearranged things, leaving assert_cmd-2.1.3 unable to locate rillmere_exec's executable target. The diagnostic from assert_cmd-2.2.2 is clearer: CARGO_BIN_EXE_rillmere_exec is unset. Reading that makes me wonder whether assert_cmd supports this situation at all. I can't imagine nobody else has run into it. Has anyone found a solution?

The conversation continues 4

Follow the reasoning

nell3 days ago Permalink
I'm afraid the choices are limited to these

-

Shift as much as you can from main.rs into lib.rs (afaik that's already typical in serious projects). Let main.rs merely invoke it. You could even leave main.rs calling a single line :v, making the code easier for another project to use

-

Test it manually by compiling the executable, starting it and inspecting errors through std::command
linocut3 days ago Permalink
If depending on nightly Rust works for you, artifact dependencies (https://doc.rust-lang.org/cargo/reference/unstable.html#artifact-dependencies) should let you declare a dependency directly on the executable required here.
yaro3 days ago Permalink
Following an earlier reply ↗
Oh, excellent! That's precisely the feature I'm looking for. Requiring nightly for this specific integration test is fine with me. I'd still like stable Rust to compile everything else in the crate, though. That leaves working out how to omit this test with a stable compiler. Perhaps the whole test will need a crate of its own. Less than ideal, but workable. I'd rather do that than relocate everything from my binary into the library.
darning3 days ago Permalink
Following an earlier reply ↗

Requiring nightly for this specific integration test is fine with me

artifact dependencies are unstable functionality in cargo, rather than in the rustc compiler.

sadly, cargo manifests have no equivelent of a conditional compilation flag, so enabling that unstable functionality just for an individual integration test while leaving the package's remaining crates usable by stable cargo isn't possible, since stable cargo cannot even read that manifest.

using artifact dependencies therefore means putting the integration-test crate in a seperate package (actually, a separate workspace), giving it a Cargo.toml distinct from those belonging to the remaining packages.

How can integration tests execute a different workspace crate's binary?

The conversation continues 4

Other sides of the same question

Reducing docker-compose console noise

Could D produce Python extension modules rather than using C?

Micro plugins declared through Nix?🤔