Update testing.md to reflect changes to cargo new #37368
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
I recently confronted this for the new book's testing chapter: rust-lang/book#288 maybe a similar approach would be good? I think I did what you did, but it's late and I'm tired; will re-read this PR tomorrow.
👍 IIRC this was due to a limitation of long-ago Rust. |
|
Ah, interesting. @rust-lang/docs what do you think we should do here? |
|
Ahh cool. I didn't realize there was a new book underway. I'm happy to take a look at that and use it as an example for making the existing docs reflect the current state of Once we have clarity on what to do around |
|
☔ The latest upstream changes (presumably #37514) made this pull request unmergeable. Please resolve the merge conflicts. |
| mod tests { | ||
| #[test] | ||
| fn it_works() { | ||
| } |
|
@steveklabnik: I like these changes so 👍 for me. |
|
@trotter I would like to merge this, can you rebase and fix that spacing issue @GuillaumeGomez pointed out? |
`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.
I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.
|
@steveklabnik Updated, but I want ensure that I didn't muck things up with the removal of |
| @@ -78,10 +79,12 @@ So why does our do-nothing test pass? Any test which doesn't `panic!` passes, | |||
| and any test that does `panic!` fails. Let's make our test fail: | |||
|
|
|||
| ```rust | |||
| # fn main() {} | |||
There was a problem hiding this comment.
so, testing this, i still get a link like
https://play.rust-lang.org/?code=fn%20main()%20%7B%7D%0A%23%5Btest%5D%0Afn%20it_works()%20%7B%0A%7D%0A
which has the main, not wrapping the example.
|
@ollie27 i'm not seeing the behavior you're talking about, am i missing something? |
# fn main() {}
#[test]
fn it_works() {}produces: https://play.rust-lang.org/?code=fn%20main()%20%7B%7D%0A%23%5Btest%5D%0Afn%20it_works()%20%7B%7D%0A #[test]
fn it_works() {}produces: https://play.rust-lang.org/?code=fn%20main()%20%7B%0A%23%5Btest%5D%0Afn%20it_works()%20%7B%7D%0A%7D # // please don't add fn main
#[test]
fn it_works() {}Only the third one shows the "Test ▶" button in the playground. Just removing |
|
Oh, the isuse is the test button not being valid. @trotter can you take away the |
|
@steveklabnik Yep! That's what I'm planning on getting fixed before saying we're done 😄 |
Without these changes, play.rust-lang.org (as of today) would wrap
our examples in `fn main() {}`. This prevents the user from being able
to easily run the tests.
The narrative flows better if we follow what @steveklabnik is doing in rust-lang/book#288. Therefore, I completely copied it.
I had used `/tmp/adder` for my previous commits. Flipped over to `/home/you/projects/adder` for consistency with other parts of testing.md
|
@steveklabnik This should be good to merge now. I've fixed the examples such that play.rust-lang.org will correctly run the code as tests. I also removed my earlier additions of |
|
Well, still remain a good big squash. :p |
|
Whoah, it just looks for |
|
Fun. I had been running |
|
I went ahead and took a quick look. It appears that the doc tests are attempting to run the code and are failing because it has no main function. I see two quick ways to making it happy:
My preference is to go with number 2 for now, but I'd also love to know if anyone has thoughts on how to get |
alexcrichton
added
the
A-docs
|
I am also leaning towards |
While the commit message on this one sounds terrible, it's really not so
bad. The issue is that our test runner _expects_ a `fn main() {}` in
code blocks that it'll test, but this code really shouldn't have them.
If it did, then clicking the "play" link in the docs would result in
play.rust-lang.org not treating this code as a test example to be run.
|
@steveklabnik OK, I pushed up the changes with |
|
Considering the current situation, I think it's ok. Thanks for all your work here @trotter! |
|
@bors: r+ rollup Yup, let's merge. If anyone else has an issue, please let me know 😄 |
|
📌 Commit 2a832a0 has been approved by |
Update testing.md to reflect changes to cargo new
`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.
I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.
Update testing.md to reflect changes to cargo new
`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.
I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.
Rollup of 30 pull requests - Successful merges: #37190, #37368, #37481, #37503, #37527, #37535, #37551, #37584, #37600, #37613, #37615, #37659, #37662, #37669, #37682, #37688, #37690, #37692, #37693, #37694, #37695, #37696, #37698, #37699, #37705, #37708, #37709, #37716, #37724, #37727 - Failed merges: #37640, #37689, #37717
cargo newnow creates asrc/lib.rswith atestsmodule by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I think it should be broken apart, with the module concept being introduced early on, and thesuperconcept being addressed when we hit theadd_twoexample. I'd like to get agreement on that being the right approach before I do it though.I also removed the
#fn main() {}hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it should cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.