make code compiled with cfg(test) visible across crates

[toxeus]

I find myself creating test helpers/mocks in my test modules that are marked with #[cfg(test)]. They are exported as pub and can conveniently be used throughout the crate.
These helpers are not visible from other crates nor from integration tests in particular.

Making code compiled with cfg(test) be visible outside of the scope of a crate would allow for better code reuse. Please consider adapting that behavior.

Related: rust-lang/rust#45599

[TomzBench]

I have a util crate that exports some mocks. Real code imports a real routine from the crate and test code imports a mock routine from the crate. However this does not work!

Is there a way to implement this or do I have to stuff everything with a mock in the same crate?

As work around I declare the mock in the crate that needs the mock, but then I have to duplicate this mock in every crate :(

[oldgalileo]

As work around I declare the mock in the crate that needs the mock, but then I have to duplicate this mock in every crate :(

Did you ever come up with or find a more ergonomic solution to this? After running into this, I've been very surprised at this being a largely unresolved issue. It seems like it would be more of a common practice to, for example, provide a once_cell::sync::Lazy initialization of cool_library::InterestingStruct which has private fields so that you don't need to compromise good visibility hygiene for testability.

So far, I've seen suggestions for mock crates, or a "testing" feature-flag with #[cfg(not(testing))] -> panicking. These seem like hacks.

[oeed]

While this would be nice to have, you can replicate this in a less nice way using crate features. On your utils crate, add a feature, e.g. test-utils, tag modules with #[cfg(feature = "test-utils")] and then on your consumer crate add:

[dev-dependencies]
my-crate = {path = "../my-crate", features = ["test-utils"]}

[simsekgokhan]

Also facing this problem, thx for the "feature" workaround. This is how I used the workaround if anybody needs: 0LNetworkCommunity/libra-legacy-v6@6106c07, look for "ol-smoke-test".

[ryoqun]

While this would be nice to have, you can replicate this in a less nice way using crate features. On your utils crate, add a feature, e.g. test-utils, tag modules with #[cfg(feature = "test-utils")] and then on your consumer crate add:

[dev-dependencies]
my-crate = {path = "../my-crate", features = ["test-utils"]}

I'm seriously thinking about coping with the limitation described in the issue... @oeed this work around looks nice but i think it's affected by cargo's feature unification, right?
in my testing, it seems that other member crates of my workspace are seeing #[cfg(feature = "test-utils")] -ed code even without proper dev-dependencies and narrowing down cargo check with -p foo actually causes expected compile errors...

[jaques-sam]

While this would be nice to have, you can replicate this in a less nice way using crate features. On your utils crate, add a feature, e.g. test-utils, tag modules with #[cfg(feature = "test-utils")] and then on your consumer crate add:

[dev-dependencies]
my-crate = {path = "../my-crate", features = ["test-utils"]}

How to enable the feature for a integration test?

[ryoqun]

While this would be nice to have, you can replicate this in a less nice way using crate features. On your utils crate, add a feature, e.g. test-utils, tag modules with #[cfg(feature = "test-utils")] and then on your consumer crate add:

[dev-dependencies]
my-crate = {path = "../my-crate", features = ["test-utils"]}

I'm seriously thinking about coping with the limitation described in the issue... @oeed this work around looks nice but i think it's affected by cargo's feature unification, right? in my testing, it seems that other member crates of my workspace are seeing #[cfg(feature = "test-utils")] -ed code even without proper dev-dependencies and narrowing down cargo check with -p foo actually causes expected compile errors...

FYI, I implemented this with the quoted concern being addressed. If interested, please look for dev-context-only-utils at https://github.com/anza-xyz/agave

It seems dev-context-only-utils is working as expected over 1 year at the moderate cost of increased CI to detect any misuse of the special feature.

Note that I recently encountered a minor problem: #10958, see extended explanation as well: #10958 (comment)

In near (?) future, I'm going to publish cargo-dcou or something for ease of use...

[HatemMn]

Hello, any news on this ? I also use the features = ["test-utils"] method for now but It would be cool that cgf=test could be exported

[epage]

As tagged, this needs design work to move forward. The problem here is that cfg(test) is only applied to test binaries. For unit tests, we build a separate copy of the library as a test binary.

If we always built the library with --cfg test then we'd be building a second copy of it, unable to reuse the original. This would increase build times for people who don't need this.

This also has people muddy the water between white box tests (in the lib) and black box tests (in tests/) and having special access to the lib shouldn't be a default path.

imo the best route forward is the self-enabled feature while making sure to do test-compiles without dev build targets enabled to catch accidentally relying on this behavior. In the short term, I'd prefix the feature with unstable- and in the long term, I hope we get private features (there is an issue for this). We might want to find a way to document this pattern.