Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cfg(test) is not set during integration tests #84629

Open
Timmmm opened this issue Apr 27, 2021 · 5 comments
Open

cfg(test) is not set during integration tests #84629

Timmmm opened this issue Apr 27, 2021 · 5 comments
Labels
A-libtest Area: `#[test]` / the `test` library C-feature-request Category: A feature request, i.e: not implemented / a PR. T-testing-devex Relevant to the testing devex team (testing DX), which will review and decide on the PR/issue.

Comments

@Timmmm
Copy link
Contributor

Timmmm commented Apr 27, 2021

#[cfg(test)] is not set when running integration tests. That page says:

[Integration tests] use your library in the same way any other code would, which means they can only call functions that are part of your library’s public API.

But that sounds to me more like it's talking about pub, pub(crate) and so on.

There's an unsatisfying workaround but it would be a lot simpler if #[cfg(test)] was simply enabled for integration tests. (Here's another person tripping up on this.)

The only reason not to do that seems to be a philosophical objection to using hidden APIs in integration tests. I don't agree with that. I'm sure others don't. But even if you subscribe to that philosophy you can simply not use the #[cfg(test)] functions in your integration tests (or don't export them). The situation for people who don't subscribe to that philosophy is much more awkward.

Changing this behaviour would also fix #45599.

@ghost
Copy link

ghost commented Jul 24, 2021

#[cfg(test)] is not set when running integration tests.

I believe #[cfg(test)] means "the test harness is used" (i.e. #[test] is active): https://doc.rust-lang.org/nightly/reference/conditional-compilation.html#test. Setting it in a library where #[test] is not active would be very unexpected to me. I'd suggest a different cfg like #[cfg(integration_test)].

@Timmmm
Copy link
Contributor Author

Timmmm commented Jul 24, 2021

That's a great idea, than you can do any(cfg(test), cfg(integration_test)) if you want.

@Timmmm
Copy link
Contributor Author

Timmmm commented Jul 24, 2021

Although a significant downside is that it adds another variant of the crate that you have to compile, which uses more disk space & time and makes things more complicated for IDEs.

@ghost
Copy link

ghost commented Jul 24, 2021

Although a significant downside is that it adds another variant of the crate that you have to compile, which uses more disk space & time and makes things more complicated for IDEs.

That downside is not specific to integration_test though. You will have two variants even if you use test:

  • a binary crate variant that runs all #[test]s
  • a library crate variant with #[cfg(test)] enabled but #[test] disabled

@Timmmm
Copy link
Contributor Author

Timmmm commented Jul 25, 2021

Good point. Perhaps the standard #[test] compilation could compile it as a library too (and then link with the test runner).

@Dylan-DPC Dylan-DPC added the C-bug Category: This is a bug. label Feb 13, 2023
@fmease fmease added C-feature-request Category: A feature request, i.e: not implemented / a PR. A-libtest Area: `#[test]` / the `test` library and removed needs-triage-legacy labels Jan 25, 2024
@fmease fmease added T-testing-devex Relevant to the testing devex team (testing DX), which will review and decide on the PR/issue. and removed C-bug Category: This is a bug. labels Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-libtest Area: `#[test]` / the `test` library C-feature-request Category: A feature request, i.e: not implemented / a PR. T-testing-devex Relevant to the testing devex team (testing DX), which will review and decide on the PR/issue.
Projects
Status: No status
Development

No branches or pull requests

4 participants