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

Add support for doctests #16

Open
sunshowers opened this issue Feb 8, 2022 · 4 comments
Open

Add support for doctests #16

sunshowers opened this issue Feb 8, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@sunshowers
Copy link
Member

sunshowers commented Feb 8, 2022

Currently, nextest doesn't support Rust doctests. This is because doctests are not exposed in stable Rust the way regular test binaries are, and are instead treated as special by cargo test.

One nightly-only fix that might work is to collect doctest executables through -Z unstable-options --persist-doctests. However, this isn't a stable approach so it must be used with care.

Note: You can run cargo test --doc as a separate step from cargo nextest run. This will not incur a performance penalty: cargo nextest run && cargo test --doc will not cause any more builds than a plain cargo test that runs doctests.

@sunshowers sunshowers added the enhancement New feature or request label Feb 8, 2022
@sunshowers sunshowers added this to the nextest-future milestone Feb 8, 2022
@xd009642
Copy link

So I use the --persist-doctests attribute and can share some of the issues I've faced with it, (hopefully more people using it will lead to stabilisation and improvements). So if we have a doctest with the should_panic attribute cargo test compiles and runs it and checks if the return code is non-zero, and the test passes only if it's non-zero.

However, the doctest file name is made from a normalisation of the path (all path separators replaced with _, a line number and a number to ensure the files are unique. This is because a doctest on the same line in src/foo/bar.rs and src/foo_bar.rs would otherwise generate the same filename. The line numbers are also done after macro expansion so things like include_str can make it harder to match line numbers with attributes.

I made an issue in rust about bundling attribute information into the file name to make it easier for people writing tools using this feature rust-lang/rust#92597 and if you're interested in seeing my code it's in https://github.com/xd009642/tarpaulin in src/cargo.rs, it's reasonably stable the issues mentioned above are the only parts it can fail. I've had this since the nightly flag was created and the naming convention has only changed once so I've only had one completely unexpected issue that affected all users that cause persist-doctests to be added.

Hope this is helpful, nextest looks pretty nifty 🎉

@WaffleLapkin
Copy link

There are also --test-builder/--runtool unstable flags that are used by miri to run doc tests

@nu11ptr
Copy link

nu11ptr commented Apr 22, 2022

Can I suggest that until this is added this is called out in the docs in a visible way? I recently was made aware how tricky doctests are to handle, but other users might not be aware. Your crate seems quite nice based on my limited usage, and it would be a shame if they didn't give it a fair chance because they thought it was broken and "skipping tests".

@sunshowers
Copy link
Member Author

@nu11ptr good idea -- I've added a note to the homepage along with expanding the notes on the listing and running pages f4043b1

IgnisDa added a commit to IgnisDa/rust-libs that referenced this issue Jan 1, 2023
elasticdog added a commit to EarthmanMuons/rustops-blueprint that referenced this issue Apr 30, 2023
Due to a limitation in how doctests are exposed in stable Rust, nextest
does not actually run them by default. We unfortunately need an explicit
step for the time being.

See:
- nextest-rs/nextest#16
bors bot added a commit to EarthmanMuons/rustops-blueprint that referenced this issue Apr 30, 2023
49: Ensure that we run the doctests r=elasticdog a=elasticdog

Due to a limitation in how doctests are exposed in stable Rust, nextest does not actually run them by default. We unfortunately need an explicit step for the time being.

See:
- nextest-rs/nextest#16

Co-authored-by: Aaron Bull Schaefer <aaron@elasticdog.com>
lgarron added a commit to cubing/cubing.rs that referenced this issue Jan 10, 2024
n-dusan added a commit to openlawlibrary/stelae that referenced this issue Jan 25, 2024
nextest currently does not run documenation tests, see this [1] issue. [1] - nextest-rs/nextest#16
github-merge-queue bot pushed a commit to software-mansion/scarb that referenced this issue Apr 10, 2024
Nextest does not support doc tests
nextest-rs/nextest#16

- **Fix doc tests**
- **Run doc tests as part of CI**
Hocuri added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 11, 2024
Nextest doesn't run doc tests, so we need to run them with
`cargo test --doc`.

See nextest-rs/nextest#16
Hocuri added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 11, 2024
Nextest doesn't run doc tests, so we need to run them with
`cargo test --doc`.

See nextest-rs/nextest#16
Hocuri added a commit to deltachat/deltachat-core-rust that referenced this issue Apr 14, 2024
Nextest doesn't run doc tests, so we need to run them with `cargo test
--workspace --doc`.

See nextest-rs/nextest#16

Follow-up for #5457
Hofer-Julian added a commit to Hofer-Julian/rattler that referenced this issue Jul 8, 2024
Cargo nextest doesn't run doctest so we missed that:
nextest-rs/nextest#16
baszalmstra pushed a commit to conda/rattler that referenced this issue Jul 8, 2024
Cargo nextest doesn't run doctest so we missed that:
nextest-rs/nextest#16
github-merge-queue bot pushed a commit to linebender/vello that referenced this issue Nov 11, 2024
As [`cargo-nextest` does not support running doc
tests](nextest-rs/nextest#16), we need a
`cargo test --doc` step as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants