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

Should examples be unit-testable? #5437

Closed
ehuss opened this issue Apr 28, 2018 · 2 comments · Fixed by #5464
Closed

Should examples be unit-testable? #5437

ehuss opened this issue Apr 28, 2018 · 2 comments · Fixed by #5464

Comments

@ehuss
Copy link
Contributor

ehuss commented Apr 28, 2018

As part of #5384, I changed it so that examples aren't unit-tested (to be consistent), but I'm having second thoughts since it is a breaking change (and probably doesn't make complete sense).

If they should be unit-testable, under which circumstances should they be tested? I think the old behavior was a little confusing (sometimes they were tested, sometimes they weren't).

We could treat them like bins (compile twice, once as a test, once regularly), but that would cause cargo test to build examples twice for the vast majority of users who don't use this.

Another idea is to only compile them as tests if test = true is set for the example in Cargo.toml.

I'd also be fine with restoring the old behavior.

For reference, here is a list of crates on crates.io that have #[test] in an example:

vst-0.0.1
alga-0.5.3
algebra-0.2.0
algs4-0.7.0
combine-3.1.0
dessert-0.1.2
error_def-0.3.16
gauthz-0.1.0
i2cdev-0.4.0
iron-test-0.6.0
jsonnet-rs-0.5.0
nickel-0.10.1
parrot-0.1.0
partial-io-0.3.0
pathfinding-0.7.1
plague-0.6.3
proptest-0.5.1
rustcov-0.0.0
simple-munin-plugin-0.1.0
topdown-rs-0.3.3

@alexcrichton
Copy link
Member

I personally like the idea of test = true being an opt-in for examples, I think that makes a lot of sense!

@Mark-Simulacrum
Copy link
Member

I agree with making this opt-in by default, but perhaps it would be nice to have a heuristic that warns if #[test] is present in examples but not enabled in Cargo's config? I'm not sure if that's viable from a performance standpoint but I'd otherwise be somewhat worried about discoverability of this change.

ehuss added a commit to ehuss/cargo that referenced this issue May 3, 2018
Fixes rust-lang#5437

I don't think changing the behavior was quite the correct thing to do.  This new behavior is very similar to the old with a few small differences:

```
cargo test
    ORGINAL: Only builds examples.
    NEW: Builds all examples.  Any example with `test` set is tested.

cargo test --tests
    ORIGINAL: Runs all examples as tests.
    NEW: Only runs examples as tests if `test` is set.

cargo test --examples
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)

cargo test --example foo
    ORIGINAL: Runs the given example as a test.
    NEW: (SAME)

cargo test --all-targets
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)
```
bors added a commit that referenced this issue May 3, 2018
Partially revert change to testing examples.

Fixes #5437

I don't think changing the behavior was quite the correct thing to do.  This new behavior is very similar to the old with a few small differences:

```
cargo test
    ORGINAL: Only builds examples.
    NEW: Builds all examples.  Any example with `test` set is tested.

cargo test --tests
    ORIGINAL: Runs all examples as tests.
    NEW: Only runs examples as tests if `test` is set.

cargo test --examples
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)

cargo test --example foo
    ORIGINAL: Runs the given example as a test.
    NEW: (SAME)

cargo test --all-targets
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)
```
@bors bors closed this as completed in #5464 May 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants