cargo test --all passed but cargo test failed

[quake]

Problem

different testing result between cargo test --all and cargo test

Steps

1. Clone repo: https://github.com/quake/cargo-test
2. run cargo test --all, passed
3. run cargo test, failed

Possible Solution(s)

Notes

Output of cargo version:
cargo 1.31.0 (339d9f9 2018-11-16)

OS: MacOS 10.14.1

[ehuss]

I think this is to be expected. Just because a package is a member of a workspace doesn't mean that all dev-dependencies will be used all the time. Since you are not running the tests for lib2 in step 3, the dev-dependencies of lib2 are not activated. It's treated as a normal dependency. Since the dev-dependency isn't activated, that means the feature won't be turned on.

[alexcrichton]

Is this another instance of #2589 perhaps?

[ehuss]

Similar, but not the same. In that issue, they don't want features to be unified. This issue is the opposite — they are not unified because the dev-dependency is not used.

There's an interesting dynamic for how people want workspaces, dependencies, and features to work. Sometimes people want to force them to be unified (like rustc-workspace-hack), and sometimes they explicitly want them to be separate (like avoiding 'std' in a build-dependency poisoning your no-std crate).

The solution for this issue is to either not expect the feature to be enabled, or enable it from the foo crate.

[quake]

I think this is to be expected. Just because a package is a member of a workspace doesn't mean that all dev-dependencies will be used all the time. Since you are not running the tests for lib2 in step 3, the dev-dependencies of lib2 are not activated. It's treated as a normal dependency. Since the dev-dependency isn't activated, that means the feature won't be turned on.

I got it. but how it explains the output result foo 1 after running ./target/debug/foo when build with cargo build --all ?

[ehuss]

the output result foo 1 after running ./target/debug/foo when build with cargo build --all ?

Heh, that's #1796.
Just for context, there are a large number of known issues involving features, workspaces, and dependency kinds. They are mostly tracked here. There are different use cases where sometimes people want features and dependencies to be unified, and sometimes they must not be unified.

[quake]

@ehuss thanks for the information. Wrap up:

• the different result between cargo test and cargo test --all, expected design.
• the different result between cargo build && target/debug/foo and cargo build --all && target/debug/foo, bug ?

[ehuss]

Yea, I think that captures it.