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

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 (https://github.com/rust-lang/cargo/issues/15010)
• This isn't the case if we change the build.build-dir default (https://github.com/rust-lang/cargo/issues/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: https://github.com/rust-lang/rust/pull/149852

Start by locating the test code that derives the [[bin]] path from the [[test]] location, then reproduce the issue with cargo +nightly test -Zbuild-dir-new-layout and CARGO_BUILD_BUILD_DIR=build cargo test. Compare this lookup with runtime CARGO_BIN_EXE_* handling, including integration-test-only availability. Done means binary lookup works with current and new Cargo build layouts without relying on Cargo internals.