binaries built by `cargo test` can be different from those built with `cargo build`

[silence-coding]

Problem

When the cargo test is executed, the binary built by the cargo build is overwritten as the result of the cargo test build.

test-build.zip

├── Cargo.lock
├── Cargo.toml
└── test-bin
    ├── Cargo.toml
    ├── src
    │   ├── lib.rs
    │   └── main.rs
    └── tests
        └── xxx_test.rs

Steps

1. cargo test
2. cargo uild
3. cargo test

Binaries will be overwritten constantly.

Possible Solution(s)

The cargo test should not modify the bin, but only the compiled test bin.

Notes

No response

Version

cargo 1.68.0 (115f34552 2023-02-26)
release: 1.68.0
commit-hash: 115f34552518a2f9b96d740192addbac1271e7e6
commit-date: 2023-02-26
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Linux [64-bit]

[epage]

This is expected behavior for cargo and is important for integration tests to do end-to-end testing of the binaries.

btw something that would be useful in an issue like this is to focus on the negative impact on the behavior. This issue does not say why this is bad and should change.

[silence-coding]

This is expected behavior for cargo and is important for integration tests to do end-to-end testing of the binaries.

btw something that would be useful in an issue like this is to focus on the negative impact on the behavior. This issue does not say why this is bad and should change.

After our project is built, the cargo test is executed for preliminary verification. However, because I have enabled different features in dev-dependencies, I am troubled by why the binary functions are inconsistent with my actual expectations when I use debug binary to verify functions in the development environment.

[silence-coding]

I didn't know that test and build would share the built binary, which was a little strange to me. Just like why dependencies merge the features of dev-dependencies when resolver = "2" is not enabled.

[weihanglo]

Feature unification is a "global" stuff. It unifies features across each Cargo target. From my point of view the purpose of it is to reuse as many build artifacts as possible.

If you want to avoid this behavior, you maybe remove activated features from that dev-dependency. Set those features in test.required-features in Cargo.toml. Then run Cargo targets separately, e.g., cargo test --test xxx_test --features "tokio/full". It is not ergonomic, and that's why we have an RFC trying to improve the situation: rust-lang/rfcs#3374.

[silence-coding]

Reuse is a good thing, but I think the premise of reuse is that you shouldn't modify the original finished product.