How the binary under test is looked up relies on internals of Cargo and will break with existing / upcoming features

[epage]

Tests assumes the location of the [[bin]] based on the location of a [[test]]

• This isn't the case when a user sets build.build-dir (added as of Cargo 1.91)
• This isn't the case if we approve the new build-dir layout (Re-organize build-dir by package + hash, rather than artifact type rust-lang/cargo#15010)
• This isn't the case if we change the build.build-dir default (Move build-dir out of the workspace to cargo-cache-home by default rust-lang/cargo#16147)

You can reproduce this by running either:

$ cargo +nightly test -Zbuild-dir-new-layout
$ CARGO_BUILD_BUILD_DIR=build cargo test

In Cargo 1.94, CARGO_BIN_EXE_* was stabilized for use at runtime, , see assert_cmd::cargo::cargo_bin for an example which supports both old and new Cargo versions.

Libraries that provide this look up as an API include:

• https://crates.io/crates/executable-path
• https://crates.io/crates/assert_cmd
• https://crates.io/crates/snapbox

Common other problems to watch for:

• Mixing this with old versions of the libraries listed above that also need updating
• Doing this lookup during unit tests when the binary is only guaranteed to be around for integration tests (and CARGO_BIN_EXE_* is only exposed to them)

This problem was identified by the following crater run: rust-lang/rust#149852

[epage]

Sorry, I was analyzing both github and crates.io crater results and forgot to de-duplicate the repos I was reporting to.